Juce Demo won't run on 10.5

I wanted to test kiosk mode in the stock Juce Demo on different versions of OS X. I built the Juce Demo using the latest tip (994f1de977) and Xcode 4.2.1 on Lion 10.7 with the standard settings (Deploy Target: 10.4). I was able to successfully run the Juce Demo on 10.7 and 10.6.
However it crashes on startup on 10.5. I don’t have Xcode on my 10.5 drive so the best I can do is give you the non helpful error message:

Does it crash right away or only when you load a specific demo?

The app I’m working on runs fine on 10.5 (I had to put in a fix to get the native file selector to work, but Jules put that in weeks ago). I haven’t refreshed for a few days, but I’ll try again tonight (the 10.5 machine is at home). I’ll also try the demo.

One thing that does come to mind, you’ll need to set the arch to 32 bit. I think that Introjucer pickes “Standard”, which, with the Lion SDK/XCode means 64 bit only. That would typically run on 10.6/10.7, but will crash on a typical 10.5 machine.

It crashes right away.

When I tried previously my architecture was set to $(NATIVE_ARCH). So I tried again setting it to 32-bit specifically. However, I still get the same crash on 10.5.
I ran the file command and it confirms that it is a 32-bit binary.

file JuceDemo.app/Contents/MacOS/JuceDemo
JuceDemo.app/Contents/MacOS/JuceDemo: Mach-O executable i386

I’ll pull the latest and try on 10.5 tonight. Again, I’ve been on the modules branches awhile, and have been running on 10.5, so it is probably something very recent.

Well, for me, the tip runs on 10.5 (deployment set to 10.4, Intel 32 bit) if I build for ‘running’ (Debug). But if I build for release, I see the window for a few moments, then boom. The crash dump is:

Process:         JuceDemo [653]
Path:            /Users/joe/Downloads/JuceDemo.app/Contents/MacOS/JuceDemo
Identifier:      com.rawmaterialsoftware.jucedemo
Version:         2.0.0 (2.0.0)
Code Type:       X86 (Native)
Parent Process:  launchd [210]

Interval Since Last Report:          710 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  68 sec
Per-App Crashes Since Last Report:   1

Date/Time:       2012-02-22 19:38:50.333 -0800
OS Version:      Mac OS X 10.5.8 (9L31a)
Report Version:  6
Anonymous UUID:  4F35427E-F75B-4D90-ADF2-36024FBE90C2

Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
  Referenced from: /Users/joe/Downloads/JuceDemo.app/Contents/MacOS/JuceDemo
  Expected in: /usr/lib/libstdc++.6.dylib

There are a lot more changes in the tip than I expected (Jules added a mechanism for Android unique activity names, which conflicts with the one I had stuffed in, etc.) So I won’t have a chance to merge the tip with stuff I use and try it with my ap on 10.5 until tomorrow. It could be that the Demo uses something I do not, so it will be interesting to see if I crash. I may not have built a release version of JuceDmo since I switched to Modules (now back to Master), but I definitely do release version of my app.

Though it looks like there is some missing variant of the __ostream_insert template. Odd.

Looks like a dynamic library mismatch, but I’m a bit stumped as to what to suggest. Your help would be much appreciated on this one, chaps, since I no longer have a 10.5 machine!

I know the feeling. I have to go to my son’s hand-me-down Mac Mini to test 10.5. I got myself merged to the latest tip this morning, so I’ll test my app tonight. If I crash too, I’ll start rolling back commits until I find where the problem appears. If it doesn’t… I guess I’ll have to try something else! :wink:

Update: My son needed his computer last night, but I tested my app (built from the tip) this morning, no crash.

I’ll look closely at the project compiler settings and, if nothing stands out, I’ll put some good old fashioned native alerts in the Juce Demo to see where it is crashing. Sorry, this is kind of a low priority for me, but I’ll keep at it.

jfitzpat: What OS are you compiling on? What version of xcode are you using?

I just tried building the Juce Demo using the latest tip (a6c99929575) and I am still getting the same cryptic crash as I got before.

First I did a (32-bit Debug) Juce Demo build on:
Xcode 4.2.1
OS X Lion 10.7.2

That worked on 10.7, 10.6 but failed on 10.5 with the error above.

Next I did a (32-bit Debug) Juce Demo build on:
Xcode 4.0.1
OS X Snow Leopard 10.6.8

That build worked on 10.7, 10.6 but failed on 10.5 with the error above.

FWIW, Juce Demo in release mode is crashing on 10.5 for me as well (see above). The debug build is not. I intend to keep tracking it down, I just can’t give it much time at the moment (and only have limited access to a 10.5 machine!)

Follow up:

Building today’s tip with XCode 4.2.1, JuceDemo explodes on 10.5 when I ‘build for archive’ (release), but runs when I ‘build for running’ (debug) - same as my first test above.

The offending line is:

        // this little function just demonstrates a few system info calls
        Logger::outputDebugString (collectSomeSystemInfo());

In ApplicationStartup.cpp. If I comment this out, no more boom. If I change it to:

        // this little function just demonstrates a few system info calls
        Logger::outputDebugString ("Cryptic crashes suck\n");

It still explodes. The Logger function itself is super simple:

void Logger::outputDebugString (const String& text)
    std::cerr << text << std::endl;

In juce_mac_SystemStats.mm. And the crash log is stream related. It certainly seemed like I had found the culprit, but why?

The only thing I could think of was that the compiler was not properly resolving between libc++ (newer) and libstdc++ (only one available on lower deployment targets. So, I changed the compiler from Apple LLVM 3.0 to LLVM GCC 4.2 under build options, and, sure enough. The explosion is gone.

FWIW, I’ve been building an application with Apple LLVM 3.0 and haven’t had any trouble with release builds on 10.5. But I’m also not using any streams to std::cerr (no Logger::outputDebugString calls).

I haven’t upgraded to 4.3 and retested yet. So I don’t know if the problem with the Apple LLVM compiler is still there. I actually won’t be able to update for a week or so (I have some other non Juce Mac and iOS stuff wrapping up), so this is as far as I can take the problem for now. I hope that helps.

Using last Friday’s build (a6c99929575), OS X Lion 10.7.2, Xcode 4.2.1 I made two 32-bit Debug builds of the Juce demo:

Build #1: No Logger::outputDebugString (collectSomeSystemInfo()); line
Build #2: Changed compiler to LLVM GCC 4.2

Tried them on 10.5 and both did not work. Both gave me the same error I’ve been getting before.

I stumped to why we are seeing different results.

Did some further research on the error message I keep getting.

After reading:


It looks like my binary contained a linker command (LC_DYLD_INFO_ONLY) that is only present in 10.6+.
When looking at the main tab for my project settings in Xcode, my deployment target said 10.4. When looking at deployment target in the build settings I see:
Debug: Compiler Default $(inherited)
Release: 10.4

I changed Debug to “10.5” recompiled (last Friday’s build (a6c99929575), OS X Lion 10.7.2, Xcode 4.2.1, 32-bit Debug) and JuceDemo worked.
I’ll give Release mode a shot with the latest tip when I get a chance.

Well, at least we have the mystery of different results solved. I was using what Jules had checked in as a baseline. You shouldn’t run into LC_DYLD_INFO_ONLY unless you are linking to a framework or library that is compiled with a deployment target 10.5 or newer. JuceDemo uses just standard Frameworks.

FWIW, here is a link to today’s tip built on 4.2.1, release. The only change was GCC compiler instead of Apple LLVM:


Runs fine on 10.4 and 10.5 here.

There are a number of bug related bug reports floating around in the Apple forums with standard streams and Apple LLVM. However, it isn’t listed as a change/fix for XCode 4.3 or LLVM 3.1 (which is reportedly the version in XCode 4.3).