I was running JUCE 1.54.27 on OS X 10.6.7 in XCode, and I kept getting these messages midway through my program:
JUCE Assertion failure in /Library/JUCE/juce_amalgamated.cpp, line 95063
Debugger() was called!
JUCE Assertion failure in /Library/JUCE/juce_amalgamated.cpp, line 95034
Debugger() was called!
These kept appearing rapid-fire, a million times. But I’m not sure what the assertion is. I went to the relevant lines in juce_amalgamated.cpp, but didn’t see any jassert()'s nearby - I assume this is because of preprocessor stuff causing the “line 95034” it spits out to correlate to something much later in the file, like around 100000 or so. So it could be anywhere and I’m not sure what my program’s doing wrong.
I thought then that it might be a good idea to compile with the static library, because then instead of saying there’s an assertion failure in juce_amalgamated.cpp, it’d spit out a specific file name instead, which would narrow it down. But now I’m getting this weird error
[quote]ld: library not found for -ljucedebug
collect2: ld returned 1 exit status
Command /Developer/usr/bin/llvm-g+±4.2 failed with exit code 1[/quote]
So my questions are:
What’s the best way to figure out what the assertion is in amalgamated.cpp? Is compiling with the static library the best way, or is there something better?
If so, then what do I do about this library not found for -ljucedebug thing? I’m not sure why that’s happening. Perhaps there’s something about the concept of a static library I don’t understand
Argh, I figured out the first issue, and it was something dumb: XCode just shows the last 6 digits of the line number and chops off the first one. So I wasn’t at line 95063, but rather something like 295063. It was CHECK_COORDS_ARE_VALID(x,y) that set it off.
I’m still curious about the -ljucedebug issue though, if anyone knows.
Did you build the static library in both release and debug modes? The error is saying that it can’t find the debug build of the juce static library, have a look in the juce/bin folder for a jucedebug.a file.
The easiest way to run and maintain a juce project is by using the modules branch from the git repository and the Introjucer found there in the extras folder. You can now independently include parts (or modules) of the juce library and the Introjucer will sort out all the linking for you.
NB it sounds like you’re on a pretty old version of Juce, there have been a few changes since then so you might have to spend a little bit of time updating things, the errors will be self explanatory and it’s well worth the effort for the new features.
I haven’t been working with the introjucer because I keep having to make changes to my project files - I want to include AudioToolbox.Framework and GLUT.Framework, as well as the BOOST libboost_system.dylib file, and I don’t know how to do it in the introjucer. But am I really on such an old version? The Introjucer is telling me this is the latest one…
Oh, nm, I didn’t see that you said the “modules” branch. Ugh, I’ve spent the last few months hacking together some commercial code (still a buggy mess), the thought of changing it all now is pretty disconcerting… I guess I’ll clean this up, upgrade, and get to cleaning again to fix whatever bugs arise.
