llvm dev - Oct 2016 - archiving LTO objects broken for current Xcode releases

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

> On Oct 26, 2016, at 8:06 AM, Jack Howarth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>    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.

Best,

— 
Mehdi

On Wed, Oct 26, 2016 at 11:12 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
>> On Oct 26, 2016, at 8:06 AM, Jack Howarth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>>    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
> Best,
>
> —
> Mehdi
>