Jack Howarth via llvm-dev
2016-Oct-26 15:06 UTC
[llvm-dev] 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
Mehdi Amini via llvm-dev
2016-Oct-26 15:12 UTC
[llvm-dev] archiving LTO objects broken for current Xcode releases
> 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
Jack Howarth via llvm-dev
2016-Oct-26 15:51 UTC
[llvm-dev] archiving LTO objects broken for current Xcode releases
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 >