Xcode 8 beta upgrade is not recognizing C++ functions
MauriceMickens opened this issue · 28 comments
After xcode 8 upgrade, readium sdk is now throwing errors in the C++ "future.h" file. "Call to unavailable function 'atomic_load': introduced in iOS 7.0" and "Call to unavailable function 'atomic_load'": Introduced in macOS 10.9.
Also, "Call to unavailable function 'atomic_compare_exchange_strong':introduced in iOS 7.0.
The sdk has been working perfectly before the xcode update so it seems to be an issue of how the ide is now reading c++ functions from the std library.
Have you tried changing the deployment target to at least 7.1? (XCode project file, search for build settings IPHONEOS_ ... something like that)
yes the deployment target for the project file and the ePub3 project are both set to 9.0.. I also tried bumping these up to 10.0 but still no luck
It looks like the lowest deployment target available is 8.0 with xcode 8
Okay thanks. I have XCode 7.3.1 which is the latest according to AppStore (latest El Capitan OSX). How did you install XCode 8?
Ah, it's XCode GM Gold Master, right? https://developer.apple.com/xcode/
Yes I was just typing that
Thanks for the quick response!
Only reason I needed to update to xcode 8 was to build on iOS 10 devices. You can get that download also from
https://developer.apple.com/download/
XCode ships with its own Clang ... so maybe this can be solved by using libc++ instead of libstdc++ ?
Something along the lines of:
CXX="clang++-$cxxver -stdlib=libc++"
CXXFLAGS="-nostdinc++ -isystem /usr/local/lib/llvm-$cxxver/include/c++/v1"
(I'm not an expert, unfortunately)
ok you adding that script somewhere in the build settings? If so, where? I tried searching for it.
I replaced the libstdc++ with the libc++.tbd library in the linked frameworks and libraries section.
I had the same problem after upgrading to XCode 8 GM.
I succeeded in compiling the project by:
- Updating the ePub3 subproject to recommended settings (in the Issue navigator),
- In the Build settings of the subproject, section "Apple LLVM 8.0 - Language - C++", "C++ Language Dialect", set to "C++11 [-std=c++11]",
Just changing the "C++ Language Dialect" wasn't enough to get rid of the errors, but updating to the recommended settings did.
Thanks Olivier! I have confirmed this works for Xcode 8 GM.
Hello,
"Updating the ePub3 subproject to recommended settings (in the Issue navigator)." Where can i change this ?
XCode's "issue navigator" normally offers the option to fix settings.
unfortunately, i've not this option to fix issues on xcode issues navigator
I have made some search on web, but nothing to help me to fix this ...
@neo6583 I would try to restore the project files to their state before you upgraded to Xcode 8, maybe from a Time Machine backup.
Or you may try to select the project in the Project navigator, then use Validate Settings... from the Editor menu.
Olivierkorner, it works ! thanks
Just a little note: as Olivier has written above, you need to change the deployment target of your app to 8.0. However, you need to also change the deployment target of the ePub project itself to 8.0. Usually it is called "ePub-iOS" in most projects that use the Readium SDK, and you should go to the Build Settings of "ePub-iOS" and then change its deployment target to 8.0. I found out that, after doing that, I was able to compile the Readium SDK without a problem in Xcode 8.
FIY you will still be able to compile the project on Xcode 7 after the changes.
Did anyone manage to Archive the ePub3 project with Xcode 8? I get the following linker error when it tries to strip the libePub3-iOS:
0 0x107f7f5cc __assert_rtn + 144 1 0x107fdcfd9 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 0x10800c30e ld::tool::SectionRelocationsAtom<arm64>::encode() + 62 3 0x107fe3e5d ld::tool::OutputFile::updateLINKEDITAddresses(ld::Internal&) + 413 4 0x107fdd4cb ld::tool::OutputFile::write(ld::Internal&) + 167 5 0x107f8069e main + 1421 6 0x7fffa06fc5ad start + 1 A linker snapshot was created at: /tmp/strip.wTI5RP-2016-08-23-152430.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
I'm able to archive the project by setting ePub3-iOS's "Strip Linked Products" to NO, but it's probably not ideal.
@mmenu-mantano Thanks for the suggesting setting "Strip Linked Products" to NO. I ran into the same error you describe above when creating an archive for deployment.
Were you able to actually launch the epub reader in your application?
It's crashing on me now, when I attempt to launch the epub reader. Here's what I was able to capture from the device logs.
: Service exited due to signal: Segmentation fault: 11
Sep 27 08:25:41 Maurice-Mickenss-iPad SpringBoard[55] : HW kbd: Failed to set (null) as keyboard focus
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : unable to find offset 0x816fcaac in shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : unable to find offset 0x818fdda8 in shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : Invalid offset 2173689256 into shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : unable to find offset 0x818fdda8 in shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : Invalid offset 2173689256 into shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : unable to find offset 0x818fdda8 in shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : Invalid offset 2173689256 into shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : unable to find offset 0x818fdda8 in shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad diagnosticd[84] : Invalid offset 2173689256 into shared cache for arch 'arm64'
Sep 27 08:25:41 Maurice-Mickenss-iPad ReportCrash[826] : platform_thread_get_unique_id matched 385297
Sep 27 08:25:41 Maurice-Mickenss-iPad ReportCrash[826] : Formulating report for corpse[825] Handbook
Sep 27 08:25:41 Maurice-Mickenss-iPad ReportCrash[826] : Saved type '109(109_Handbook)' report (1 of max 25) at /var/mobile/Library/Logs/CrashReporter/Handbook-2016-09-27-082541.ips
Sep 27 08:25:41 Maurice-Mickenss-iPad SpringBoard[55] : Application 'UIKitApplication:com.duke-energy.swift.Handbook[0x7ff4]' crashed.
Sep 27 08:25:41 Maurice-Mickenss-iPad UserEventAgent[23] : 1650777679536: id=com.duke-energy.swift.Handbook pid=825, state=0
Sep 27 08:26:10 Maurice-Mickenss-iPad kernel[0] : AppleARMPMUCharger: limiting USB input current to 1500 mA
From my research, it appears "Service exited due to signal: Segmentation fault: 11" is associated with the program trying to access a zombie object.
Unless ENABLE_SYS_CACHE_FLUSH is defined, the "CPU cache util" stuff
should not be included in the build:
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/byte_buffer.cpp#L27
#ifdef ENABLE_SYS_CACHE_FLUSH
#include "CPUCacheUtils.h"
#endif //ENABLE_SYS_CACHE_FLUSH
...
...
void ByteBuffer::Clean(unsigned char *ptr, size_t len)
{
bzero(ptr, len);
#ifdef ENABLE_SYS_CACHE_FLUSH
epub_sys_cache_flush(ptr, len);
#endif //ENABLE_SYS_CACHE_FLUSH
}See:
0c6c54f
Also see:
readium/SDKLauncher-iOS#38 (comment)
On 27 Sep 2016 10:59 pm, "Olivier Körner" notifications@github.com wrote:
Looks like there's some assembler code in CPUCacheUtils. It may be
related to the arm64 architecture that is not handled by the module (only
i386, x64 and arm). Strange that it worked with prior versions of Xcode...—
@MauriceMickens: No I can open the ePub reader without crashing. But I had to put the Strip Linked Products to NO on the parent project too.
So looks like the crash I was having was totally unrelated to the readium sdk and was a bug in my code. Sorry for the false flags guys. The ePub reader is now working fine on both iOS 9 and 10 devices.
@MauriceMickens Glad it worked out. No need for an apology. We've all been there, done that...
'
TODO: file a separate issue for the archive "problem" #257 (comment) @olivierkorner
UPDATE: done #261
I met the same problem, how to solve this bug ？