search

readium / readium-sdk

A C++ ePub renderer SDK
BSD 3-Clause "New" or "Revised" License
385 stars 164 forks source link

Xcode 8 build error when archiving product #261

Closed olivierkorner closed 7 years ago

olivierkorner commented 7 years ago

This issue is a Bug

Related issue(s) and/or pull request(s)

257

260

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

A workaround is to set Strip Linked Product to NO in the Build Settings, but there might be yet unknown side effects.

olivierkorner commented 7 years ago

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!

rkwright commented 7 years ago

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?

olivierkorner commented 7 years ago

I submitted a bug report to Apple.

rkwright commented 7 years ago

@olivierkorner Thanks, Olivier? Did you get a bug reference or pointer back? If and when you do, could you please post it here?

olivierkorner commented 7 years ago

@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".
dhavalshah commented 7 years ago

Any update on this one? We are facing the same issue

feihuang89 commented 7 years ago

setting the library's 'Strip Linked Product' to NO may be helpful!

rkwright commented 7 years ago

@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"

dhavalshah commented 7 years ago

Yes 'Strip Linked Product' to NO does work but as rkwright mentioned not a permanent solution

olivierkorner commented 7 years ago

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.

danielweck commented 7 years ago

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:

https://github.com/readium/readium-sdk/issues/264#issuecomment-259920029

olivierkorner commented 7 years ago

Maybe related: https://github.com/openframeworks/openFrameworks/issues/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.

danielweck commented 7 years ago

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)

olivierkorner commented 7 years ago

Indeed, I was able to successfully archive and upload it to iTunes Connect after disabling thread_local for iOS!

danielweck commented 7 years ago

How did you disable thread_local? (code removal, or compiler option?)

olivierkorner commented 7 years ago

@danielweck I disabled it for iOS with a compiler option: https://github.com/readium/readium-sdk/blob/b36287954790201368922649479f6fccabf89d6d/ePub3/utilities/future.cpp#L130

#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 :)

danielweck commented 7 years ago

@olivierkorner but in this case, there should be a compile-time error, right? https://github.com/readium/readium-sdk/blob/b36287954790201368922649479f6fccabf89d6d/ePub3/utilities/future.cpp#L164 # error No TLS implementation for this OS/Compiler

olivierkorner commented 7 years ago

@danielweck No, because EPUB_OS(UNIX) is true

danielweck commented 7 years ago

oh, Darwin is included in this macro too, of course.

danielweck commented 7 years ago

Related / duplicate? https://github.com/readium/readium-sdk/issues/267

danielweck commented 7 years ago

@olivierkorner are you also experiencing https://github.com/readium/readium-sdk/issues/267 ?

...this should be a satisfactory solution, right?

#if EPUB_COMPILER_SUPPORTS(CXX_THREAD_LOCAL) && !EPUB_OS(IOS) https://github.com/readium/readium-sdk/blob/b36287954790201368922649479f6fccabf89d6d/ePub3/utilities/future.cpp#L130

If so, could you please create a Pull Request, so we can close this issue?

danielweck commented 7 years ago

Fixed by: https://github.com/readium/readium-sdk/pull/268