Xcode 8 build error when archiving product
olivierkorner opened this issue · 22 comments
This issue is a Bug
Related issue(s) and/or pull request(s)
Expected Behaviour
Xcode should build an archive file that you can upload to AppStore for validation
Observed behaviour
Archive process fails with error:
Strip /Users/olivierk/Library/Developer/Xcode/DerivedData/Lisa-bltmqvbwimjvbxauonpwachzptwl/Build/Intermediates/ArchiveIntermediates/Lisa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/libePub3-iOS.a
cd /Users/olivierk/Projets/lisa/Lisa/readium-sdk/Platform/Apple
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -S /Users/olivierk/Library/Developer/Xcode/DerivedData/Lisa-bltmqvbwimjvbxauonpwachzptwl/Build/Intermediates/ArchiveIntermediates/Lisa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/libePub3-iOS.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: input object file stripped: /Users/olivierk/Library/Developer/Xcode/DerivedData/Lisa-bltmqvbwimjvbxauonpwachzptwl/Build/Intermediates/ArchiveIntermediates/Lisa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/libePub3-iOS.a(CPUCacheUtils_i386.o) (for architecture armv7)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: input object file stripped: /Users/olivierk/Library/Developer/Xcode/DerivedData/Lisa-bltmqvbwimjvbxauonpwachzptwl/Build/Intermediates/ArchiveIntermediates/Lisa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/libePub3-iOS.a(CPUCacheUtils_x64.o) (for architecture armv7)
0 0x10ffa35cc __assert_rtn + 144
1 0x110000fd9 ld::tool::SectionRelocationsAtom<arm64>::encodeSectionReloc(ld::Internal::FinalSection*, ld::tool::SectionRelocationsAtom<arm64>::Entry const&, std::__1::vector<macho_relocation_info<Pointer64<LittleEndian> >, std::__1::allocator<macho_relocation_info<Pointer64<LittleEndian> > > >&) + 1609
2 0x11003030e ld::tool::SectionRelocationsAtom<arm64>::encode() + 62
3 0x110007e5d ld::tool::OutputFile::updateLINKEDITAddresses(ld::Internal&) + 413
4 0x1100014cb ld::tool::OutputFile::write(ld::Internal&) + 167
5 0x10ffa469e main + 1421
A linker snapshot was created at:
/tmp/strip.IzSI5R-2016-09-04-183645.ld-snapshot
ld: Assertion failed: (0 && "need to handle arm64 -r reloc"), function encodeSectionReloc, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-274.1/src/ld/LinkEditClassic.hpp, line 1921.
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: internal link edit command failed
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip failed with exit code 1
Steps to reproduce
In Xcode, choose Archive in the Product menu.
Product
- Native application (Readium SDK C++)
- iOS
Additional information
A workaround is to set Strip Linked Product to NO in the Build Settings, but there might be yet unknown side effects.
As suspected, the workaround has a serious downside:
Setting the Strip Linked Product setting to NO creates an archive that will not validate when uploaded to iTunes Connect for validation by Apple.
I got a message saying the binary had issues:
Non-public API usage:
The app references non-public symbols in Lisa: __tlv_atexit
I advise you to keep a copy of Xcode 7 if you need to submit a new binary to iTunes Connect!
But surely this can't have been overlooked by Apple, so what is the right answer? I.e. what is wrong with our project that we get into this state/problem?
I submitted a bug report to Apple.
@olivierkorner Thanks, Olivier? Did you get a bug reference or pointer back? If and when you do, could you please post it here?
@rkwright Yes but I think access to Apple bug reports are private.
Just in case, it's filed with ID 28684153.
Here's the information:
Summary:
After upgrading to Xcode 8, I'm unable to archive the project.
Archiving fails with a fatal error from strip when building a static library archive in a subproject.
Steps to Reproduce:
1. Open project in Xcode
2. Set active scheme to "Generic iOS Device"
3. In menu "Product", select "Archive"
Expected Results:
Archive builds without error
Actual Results:
The archive process fails when build a static library in a subproject with a fatail error in strip:
The error message says:
ld: Assertion failed: (0 && "need to handle arm64 -r reloc"), function encodeSectionReloc, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-274.1/src/ld/LinkEditClassic.hpp, line 1921.
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: internal link edit command failed
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip failed with exit code 1
Version:
Xcode Version 8.0 (8A218a)
OX X 10.11.6 (15G1004)
Notes:
The archive is built succesfully when the "Strip Linked Product" is set to NO, but when I upload it to iTunesConnect, I get an email saying there's an issue: "Non-public API usage: The app references non-public symbols in Lisa: __tlv_atexit".
Any update on this one? We are facing the same issue
setting the library's 'Strip Linked Product' to NO may be helpful!
@Africa802916 That has been tried, see @olivierkorner comment above. If you do that it creates the archive, but Apple then rejects the archive in the store.
So far, we have not found a solution and Apple has not responded to our "bug report"
Yes 'Strip Linked Product' to NO does work but as rkwright mentioned not a permanent solution
My Apple bug report has been closed:
Engineering has determined that your bug report (28684153) is a duplicate of another issue (29057575) and will be closed.
The CPUCacheUtils / assembly code is really not that critical (and can therefore be removed), in fact it normally is disabled via a preprocessor / compiler directive, see:
Maybe related:
openframeworks/openFrameworks#5317
Indeed, when I upload an archive to iTunes Connect, I get an email from Apple saying:
Non-public API usage:
The app references non-public symbols in XXX: __tlv_atexit
Indeed I see an occurence of thread_local in future.cpp.
I'm going to try to disable it on iOS and see how it goes.
in the LCP/LSD implementation, we disabled Future/Promise entirely, and we removed the pthread-related dependencies which were not necessary and were making life more complicated with some compilers (NDK, Pepper)
Indeed, I was able to successfully archive and upload it to iTunes Connect after disabling thread_local for iOS!
How did you disable thread_local? (code removal, or compiler option?)
@danielweck I disabled it for iOS with a compiler option:
readium-sdk/ePub3/utilities/future.cpp
Line 130 in b362879
#if EPUB_COMPILER_SUPPORTS(CXX_THREAD_LOCAL) && !EPUB_OS(IOS)
I wanted to add this to the pull request but looks like I'm too late :)
@olivierkorner but in this case, there should be a compile-time error, right?
readium-sdk/ePub3/utilities/future.cpp
Line 164 in b362879
# error No TLS implementation for this OS/Compiler@danielweck No, because EPUB_OS(UNIX) is true
oh, Darwin is included in this macro too, of course.
Related / duplicate?
#267
@olivierkorner are you also experiencing #267 ?
...this should be a satisfactory solution, right?
#if EPUB_COMPILER_SUPPORTS(CXX_THREAD_LOCAL) && !EPUB_OS(IOS)
readium-sdk/ePub3/utilities/future.cpp
Line 130 in b362879
If so, could you please create a Pull Request, so we can close this issue?
Fixed by: #268