archiving LTO objects broken for current Xcode releases

Project Infrastructure LLVM Dev List Archives
1

The ability to archive object files generated with -flto under
LLVM.org clang 3.9.0 or 4.0svn trunk is broken against the currently
shipping Xcode releases including the upcoming Xcode 8.1 GM.

https://llvm.org/bugs/show_bug.cgi?id=30791

$ clang-3.9 -flto -O1 -c *.i
$ ar cr libtar.a paxerror.o paxexit-status.o paxnames.o rtapelib.o
stdopen.o wordsplit.o xattr-at.o
error: Unknown attribute kind (52) (Producer: 'LLVM3.9.0' Reader:
'LLVM APPLE_1_800.0.42.1_0')
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar:
internal ranlib command failed

Using MacPorts, I've been able to confirm that archiving LTO object
files now requires a cctools release that has been built against llvm
3.9.0 rather than 3.8.1 to avoid this failure.
     Was this change intentional and is there any possibility of
restoring compatibility with the currently shipping Xcode releases?
          Jack

2

This is not a bug, and not a goal to solve this: “older” LLVM versions can’t read newer bitcode.

You need either to:

1) use llvm-ar that ships with 3.9/4.0,
2) export a DYLD_LIBRARY_PATH that points to the path where the 3.9/4.0 libLTO.dylib is. The Xcode ar will load libLTO.dylib.

If none of this fits your need, please be more specific on the use case so that we can come up with a better solution.

Best,

3

   The ability to archive object files generated with -flto under
LLVM.org clang 3.9.0 or 4.0svn trunk is broken against the currently
shipping Xcode releases including the upcoming Xcode 8.1 GM.

https://llvm.org/bugs/show_bug.cgi?id=30791

$ clang-3.9 -flto -O1 -c *.i
$ ar cr libtar.a paxerror.o paxexit-status.o paxnames.o rtapelib.o
stdopen.o wordsplit.o xattr-at.o
error: Unknown attribute kind (52) (Producer: 'LLVM3.9.0' Reader:
'LLVM APPLE_1_800.0.42.1_0')
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar:
internal ranlib command failed

Using MacPorts, I've been able to confirm that archiving LTO object
files now requires a cctools release that has been built against llvm
3.9.0 rather than 3.8.1 to avoid this failure.
    Was this change intentional and is there any possibility of
restoring compatibility with the currently shipping Xcode releases?

This is not a bug, and not a goal to solve this: “older” LLVM versions can’t read newer bitcode.

You need either to:

1) use llvm-ar that ships with 3.9/4.0,
2) export a DYLD_LIBRARY_PATH that points to the path where the 3.9/4.0 libLTO.dylib is. The Xcode ar will load libLTO.dylib.

If none of this fits your need, please be more specific on the use case so that we can come up with a better solution.

Thanks. Actually both llvm-ar and llvm-ranlib have to be used for
builds with -flto that create library archives to work.
       Jack