5

I run into this ld assertion error while building an iOS dynamic framework in command line using xcodebuild.


0 0x10163b342 __assert_rtn + 144 1 0x101678a3a archive::File<arm64>::makeObjectFileForMember(archive::File<arm64>::Entry const*) const + 1138 2 0x1016783e8 archive::File<arm64>::justInTimeforEachAtom(char const*, ld::File::AtomHandler&) const + 122 3 0x10168ea75 ld::tool::InputFiles::searchLibraries(char const*, bool, bool, bool, ld::File::AtomHandler&) const + 265 4 0x101697db8 ld::tool::Resolver::resolveUndefines() + 160 5 0x10169a117 ld::tool::Resolver::resolve() + 79 6 0x10163c060 main + 812 7 0x7fff9dd4c5ad start + 1 A linker snapshot was created at: /tmp/MyKit-2016-02-31-154836.ld-snapshot ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-253.9/src/ld/parsers/archive_file.cpp, line 355. clang: error: linker command failed with exit code 1 (use -v to see invocation) 

According to archive_file.cpp source code (http://www.opensource.apple.com/source/ld64/ld64-253.3/src/ld/parsers/archive_file.cpp) it seems there are some kind of symbol corruption while ld is loading a library. But other than that I have no clue how this issue might be fixed.

This issue shows up only when I try to build my framework with bitcode enabled by adding "-fembed-bitcode" compiler flag.

Also, in my ld command, I am trying to link against a few static libraries, one of them is > 4.25 GB (with bitcode built-in), and this size exceeds an unsigned 32-bit integer's max value (~ 3.99 GB). I previously run into a few issue with libtool related to not being able to handle large binary libs, so this is one of my suspicion.

I wonder if anyone has seen similar problems or figure out how to fix it ? Thanks

a few related questions

Weird xCode linker error I've never seen before saying "Assertion failed"

https://github.com/SciRuby/nmatrix/issues/69

http://lists.llvm.org/pipermail/llvm-dev/2013-October/066722.html

https://github.com/TrinityCore/TrinityCore/issues/14689

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438

1
  • 1
    4.25 GB static library?!? :o Commented Apr 4, 2016 at 21:17

2 Answers 2

6
+25

Do you want to read the explanation for your error, which is ld: Assertion failed: (memberIndex != 0) ...? Follow this link

Also, don't worry about the size of your static library. The linker will remove all unnecessary information in the final executable. Please read here

TL; DR version:

  1. Clean your project using Command-Option-Shift-K. Also, choose Window > Organizer and switch to the Projects tab. Click the right-arrow to the right of the Derived Data folder name, delete Derived Data folder, and restart XCode.

  2. go to Build Settings in your project's settings => find Linking->Other linker flags => add -v. This will show you the exact corrupted file that is causing your error, if it still occurs. If you have the error again, please post the path of the corrupted file here, we can work from there.

  3. The reason of your error is because one of your static library is corrupt. You can remove your 4.25gb lib and rebuild again to see if this is the problem. It is under your project's target settings -> build phases -> link binary with libraries. If the error goes away, that might be it. In this case, care to give the name of the lib?

Sign up to request clarification or add additional context in comments.

2 Comments

thanks. I've tried #1 and #2 and they are giving me the same error. -v doesn't give much additional info either. For #3, linker will complain unresolved symbol error if I remove the static library since the lib is need by other parts of the code while linking the framework.
what is the library called? Also, Generate Debug Symbols in project settings can help you reduce the size of static library when building.
1

Just adding to oasisweng's answer.

Does one of the following help?:

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.