C++ linking error in release mode


#1

Im having a linker problem seems to have crept in when I recently upgraded to Xcode 5.1. First, when I build my juce app  (Grace) in Debug mode all is fine, linking works and the app runs well. However, when I build in Release mode an error  with a juce symbol in my libjuce.a occurs at the final linking stage (-v output shown)

Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o bin/Grace.app/Contents/MacOS/Grace -lcrt1.10.6.o -Llib -Lsndlib/lib -Llib/Release -L. obj/Grace/Release/Metronome.o obj/Grace/Release/Syntax.o obj/Grace/Release/CmSupport.o obj/Grace/Release/Console.o obj/Grace/Release/Scheme.o obj/Grace/Release/Preferences.o obj/Grace/Release/SchemeSources.o obj/Grace/Release/Midi.o obj/Grace/Release/OpenSoundControl.o obj/Grace/Release/Csound.o obj/Grace/Release/Main.o obj/Grace/Release/Resources.o obj/Grace/Release/SndLib.o obj/Grace/Release/SndLibBridge.o obj/Grace/Release/Instruments.o obj/Grace/Release/Fonts.o obj/Grace/Release/Help.o obj/Grace/Release/Commands.o obj/Grace/Release/CodeEditor.o obj/Grace/Release/Documentation.o obj/Grace/Release/Audio.o obj/Grace/Release/AudioFilePlayer.o obj/Grace/Release/MidiFilePlayer.o obj/Grace/Release/Cells.o obj/Grace/Release/Plot.o obj/Grace/Release/PlotEditor.o obj/Grace/Release/PlotWindow.o obj/Grace/Release/OscPack.o -x lib/Release/libjuce.a lib/Release/liboscpack.a -lsndlib -lc++ -framework AudioToolbox -framework AudioUnit -framework Carbon -framework Cocoa -framework CoreServices -framework CoreAudio -framework CoreAudioKit -framework CoreMidi -framework ApplicationServices -framework AGL -framework IOKit -framework QuartzCore -framework WebKit -framework Accelerate -framework DiscRecording -lstdc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a

ld: internal error: atom not found in symbolIndex(__ZN4juce15HeapBlockHelper11ThrowOnFailILb0EE5checkEPv) for architecture x86_64


I searched the juce forums and found a related question ("JUCE and C++11  Wed, 17 Apr 2013 - 13:37, billythekid)  to which jules answered:

| Compiles ok for me.. There's a setting in the introjucer for selecting libc++ - try using that instead of the raw command-line params.


now, im generating makefiles using premake4 and to switch to introjucer at this point would be a huge change as my premake script handles submodules that also get build like oscpack etc.  Ive tried various incantations of -lc++  and  -std=c++11 and -stdlib=libc++  but without any luck --  can someone tell me what the  links should look like that come out of introjucer, or how I can resolve the issue?

thanks for any info.

Rick Taube
Assoc. Prof. Composition/Theory
School of Music
University of Illinois at Urbana-Champaign
Net: taube@illinois.edu
Fax: 1 217 244 7767
Vox: 1 217 244 2684

 

 


#2

Make sure the C++ compiler settings are using stdlib with C++11 support in your project settings.

Also make sure any libraries you may be using are also compiled with this option.

Rail


#3

Funny bumping into you here. The message indicates an internal linker error. These tend to be the nasty types that indicate a very low-level problem (or bug) in the linker. It looks like you have both -lc++ and -lstdc++ on the link command, and this could be confusing things. You either want to link with one of libstdc++ or libc++. libc++ is the new standard library implementation, which is the default in Xcode now. However, it could be that this has nothing to do with the problem (since it is an internal linker error and not necessarily something you did 'wrong').


#4

That was just a typo from all my flailing --- ive been trying singles of  -lc++ and -lstdc++  and also using nothing at the end of the g++ linking to get the defatul incantation and both produce the same result

ld: internal error: atom not found in symbolIndex(__ZN4juce15HeapBlockHelper11ThrowOnFailILb0EE5checkEPv) for architecture x86_64

if i call ld myself based on the -v output, I notice that -lstdc++ gives the error, but if i switch to -lc++  then its like im not linking to the c++ lib at all (lots of std:: symbols not found)

i am stumped :(

 


#5

Rail, yes thank you, i am now compilng all the juce files and my files with
     -mmacosx-version-min=10.7 -std=c++11 -stdlib=libc++

the linking is using -lc++   but i still get the same linking error. 

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.7.0 -o bin/Grace.app/Contents/MacOS/Grace -lcrt1.10.6.o -Llib -Lsndlib/lib -L. obj/Grace/Release/Metronome.o obj/Grace/Release/Syntax.o obj/Grace/Release/CmSupport.o obj/Grace/Release/Console.o obj/Grace/Release/Scheme.o obj/Grace/Release/Preferences.o obj/Grace/Release/SchemeSources.o obj/Grace/Release/Midi.o obj/Grace/Release/OpenSoundControl.o obj/Grace/Release/Csound.o obj/Grace/Release/Main.o obj/Grace/Release/Resources.o obj/Grace/Release/SndLib.o obj/Grace/Release/SndLibBridge.o obj/Grace/Release/Instruments.o obj/Grace/Release/Fonts.o obj/Grace/Release/Help.o obj/Grace/Release/Commands.o obj/Grace/Release/CodeEditor.o obj/Grace/Release/Documentation.o obj/Grace/Release/Audio.o obj/Grace/Release/AudioFilePlayer.o obj/Grace/Release/MidiFilePlayer.o obj/Grace/Release/Cells.o obj/Grace/Release/Plot.o obj/Grace/Release/PlotEditor.o obj/Grace/Release/PlotWindow.o -x -framework AudioToolbox -framework AudioUnit -framework Carbon -framework Cocoa -framework CoreServices -framework CoreAudio -framework CoreAudioKit -framework CoreMidi -framework ApplicationServices -framework AGL -framework IOKit -framework QuartzCore -framework WebKit -framework Accelerate -framework DiscRecording lib/libjuce.a -lsndlib -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a

ld: internal error: atom not found in symbolIndex(__ZN4juce15HeapBlockHelper11ThrowOnFailILb0EE5checkEPv) for architecture x86_64

 


#6

Ive also tried not using a libjuce.a file at all -- just compiling the juce sources along with my sources (and with no oscpack involved) and then linking all the .o output into the app directly. but i still get the same error.

the debug build is fine!

 


#7

I've stubbed out my code base to remove  linking to any external libs i build, at this point my project is release linking only the juce modules .o files with my app's .o files and i still fails with the same error (differnt juce symbol)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -demangle -dynamic -arch x86_64 -macosx_version_min 10.7.0 -o bin/Grace.app/Contents/MacOS/Grace -lcrt1.10.6.o  -L. obj/Grace/Release/juce_audio_basics.o obj/Grace/Release/juce_audio_devices.o obj/Grace/Release/juce_audio_formats.o obj/Grace/Release/juce_audio_processors.o obj/Grace/Release/juce_audio_utils.o obj/Grace/Release/juce_core.o obj/Grace/Release/juce_data_structures.o obj/Grace/Release/juce_events.o obj/Grace/Release/juce_graphics.o obj/Grace/Release/juce_gui_basics.o obj/Grace/Release/juce_gui_extra.o obj/Grace/Release/Metronome.o obj/Grace/Release/Syntax.o obj/Grace/Release/Console.o obj/Grace/Release/Scheme.o obj/Grace/Release/Preferences.o obj/Grace/Release/SchemeSources.o obj/Grace/Release/Midi.o obj/Grace/Release/OpenSoundControl.o obj/Grace/Release/Csound.o obj/Grace/Release/Main.o obj/Grace/Release/Resources.o obj/Grace/Release/Fonts.o obj/Grace/Release/Help.o obj/Grace/Release/Commands.o obj/Grace/Release/CodeEditor.o obj/Grace/Release/Documentation.o obj/Grace/Release/Audio.o obj/Grace/Release/AudioFilePlayer.o obj/Grace/Release/MidiFilePlayer.o obj/Grace/Release/Cells.o obj/Grace/Release/Plot.o obj/Grace/Release/PlotEditor.o obj/Grace/Release/PlotWindow.o -x -framework AudioToolbox -framework AudioUnit -framework Carbon -framework Cocoa -framework CoreServices -framework CoreAudio -framework CoreAudioKit -framework CoreMidi -framework ApplicationServices -framework AGL -framework IOKit -framework QuartzCore -framework WebKit -framework Accelerate -framework DiscRecording  -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
ld: internal error: atom not found in symbolIndex(__ZN4juce10OwnedArrayINS_11AudioSourceENS_20DummyCriticalSectionEE16deleteAllObjectsEv) for architecture x86_64
Ricks-MacBook-Pro:cm taube$

im not quite sure what to try next at this point -- i just built the juce demo in release mode and it runs...

 

 


#8

You could try building everything for i386 instead of x86_64. That would exercise a very different linker path and probably would not trip over the same linker fault.

In my experience, these internal linker errors are architecture-specific bugs. For example, I once ran into one when I casted from double to long long on an armv6 architecture. There was nothing semantically wrong with the code, just a random bad combination the linker didn't support. A workaround in your case would involve locating the code (by divide-and-conquer) that triggers the linker error and rewriting or suppressing the expression. In this case you do have the symbol __ZN4juce15HeapBlockHelper11ThrowOnFailILb0EE5checkEPv as a starting point. You would want to find the places where that symbol is used and comment out/rewrite the code so that it does not use that symbol. Again, this is almost certainly not a problem in your code or in the JUCE code. It's likely a bug in the linker. If you search for "ld internal error: atom not found" you will find many results of people reporting linker bugs.

But I would definitely just try building the project for i386 first unless you absolutely need x86_64.


#9

Thanks, andrew I really appreciate the tip, will try that this weekend! In the mean time my workaround is to compile all dependancies in xcode , if I do that then building an app in both release and debug will work. so, as much as i hate the xcode ide, i can produce a running app by adding juce and oscpack sources to my soures (no libs) and then linking to a libsndlib.a that i built via its own xcode project.

--rick

 


#10

Once you get the Xcode project set up you can invoke builds from the command line using:

xcodebuild -project path/to/project.xcodeproj -target project -configuration Release

It can also be handy to remove the Xcode build caches of the project, which it usually leaves around in ~/Library/Developer/Xcode/DerivedData/project*


#11

I'm having a similar problem now (release build):

ld: internal error: atom not found in symbolIndex(__ZN4juce10Expression7Helpers16findTermToAdjustEPNS0_4TermEb) for architecture i386

I feel like I've tried everything to no avail.. ideas ??

 


#12

Since I use CMake to generate the Xcode project, it ALWAYS adds -s as linking option for Release build. Even though the linker says the option is obsolete and will be ignored, it obviously does something, since removing that option makes the linking succeed (!)

There is no way ATM though to make CMake NOT generate the -s option so it is filed as a CMake "bug".


#13

Hi guys!

I experienced the same problem building release version of my plugin with AAX library.

The solution was simple: both projects must have the same value for “Link-time optimization” (both disabled or both enabled). This value accessible in either Introjucer or Xcode project properties (see Apple LLVM - Code Generation)