Juce Program Only Works In One Directory


#1

Hi,
I recently got started programming with JUCE and I LOVE it!
I’m on a mac and I am having one really weird problem though.
The program will only work properly from one directory where it was compiled with xcode. If I move the executable file, it won’t work anymore. Likewise, if I compile a program using NetBeans, that executable won’t work unless I put it in the xcode executable’s directory. It’s so strange. I’m new to mac, so I wonder if it’s related to mac. I’ve never seen an executable that depends on being in a particular directory. It’s quite a problem for me in the sense that I can’t execute the program from NetBeans, making it more difficult to develop.
Does anyone else have this problem?
Does anyone have a solution for me?
Thanks
Sean


#2

Yeah, on Mac, linking is a bit sensitive, but bring you more discipline in what you’re making finally.

The really matter is about library, the path is maybe relative to Juce e.g., you should wait for having finalised your code, then some manipulations are needed, to bring the library into the app bundle. Which is not all : cause you’ll have also to change the path to look for…
Not as simple as on Windows, where libs -put with the exe in the same dir- works.

But numerous other explanations.

Whatever, you should consider a BUNDLE on Mac, not a EXE.
EXE is part of a bundle with all the other rsc - framework - etc.


#3

That sounds extremely odd, I’ve never heard of anything like it before… All apps need to link to the system frameworks, so maybe the path that the system uses to find them has become corrupted or something…?


#4

Yeah, this is really odd. The program starts in other directories, but it doesn’t run properly. The top three left buttons to close minimize and maximize don’t work, and the main thing is that the window starts behind the terminal I’m using or behind netbeans. Furthermore, isActive()=0 in any other directory and =1 in the one directory where the program works normally. I’m completely lost as to what is going on.


#5

Make sure you have your bundle name set properly in your info.plist.


#6

Ok, so this has me very confused. I tried to make a bundle in xcode this morning, but I couldn’t figure out a way to get an executable when I did that. The way I tried to do it was by changing the machtype to bundle instead of executable inside of xcode. However, when I use netbeans, I don’t have an info.plist do I? If I need one, what is it, and what does it mean to set a bundle name properly within it?


#7

Don’t change to a bundle, that’s for dynamically loaded code(I’m assuming you are writing a juce application not a plugin)

read up on otool in the terminal, specifically otool -L.

Once your application is built you should be able to right click on it and share package contents, go into Contents then Mac OS, launch a terminal process and type otool -L and then drag the terminal looking “exe” onto the terminal window(this will get its full path)

it’ll then show you the path of all the libraries its loading. You don’t want any /usr/local/ stuff

(Oh, and make sure you don’t have ZeroLink on)

Or you can launch Console on the computer you are trying to get it to run on and you’ll probably see a dylib error.

It kind of sounds to be like you have created a Foundation Tool or a C++ Tool not a “Cocoa/Carbon” Application. (Perhaps its launching as a background process?)

I’d examine the JUCE_Demo target settings in XCode.

Good luck!

Oh and make sure you haven’t selected the 10.5 SDK and are trying to run on 10.4… And are you making a universal binary(perhaps your build machine is PowerPC and your test machine is IntelMac and you are building for “native architecture only”?)

Lots to think about!


#8

Wow, that is great advice! Thank you so much. I’m gradually going through all the possibilities. One thing for sure is that I do have /usr/lib/ libraries listed with otool -L. I’m not sure what to do about them yet, but here is what I get:
otool -L gview.app/Contents/MacOS/gview
gview.app/Contents/MacOS/gview:
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.18.0)
/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 49.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0)
/System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1327.0.0)
/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 530.18.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.46.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.24.0)


#9

/usr/lib is ok they are on other computer’s. (Well depending on the OS SDK! ie…build for 10.4u and you’ll be ok on machines running 10.4 and higher) But if you have done any ./configure - make - make install on 3rd party libraries these go into /usr/local/lib which would be specific to the machine. You’d have to have added that path to xcode though for linking(either by dragging in a built library from the directory or adding a -library path to xcode’s settings). Same for fink / macports(go into /opt/local I think)

Those all look ok, i’d look at the console log of the machine that doesn’t launch your app…/Applications/utilities/console


#10

you might also find the ‘nm’ command line tool useful as well, since it shows what you are linking to at run time. The generated list will be long, so pipe it into a text file. The main point of interest is the second column that describes the linking type for various functions.

BTW, I’m moving this into the Mac forum, since a) that’s where it belongs, and b) it’ll be more easily located for anyone else who may run into this problem in future.


#11

otool -L /Applications/utilities/Console.app/Contents/MacOS/Console
/Applications/utilities/Console.app/Contents/MacOS/Console:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.16.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.43.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.22.0)


#12

with nm, I have many types of things in the second column. A unique list is:
A
D
S
T
U
b
d
s
t


#13

It’s fine to move this to a mac forum. Just let me know a link to that site.


#14

By the way, I tried using the otool -L on the same program in a directory where it works and a directory where it doesn’t work correctly, and the same libraries are being used both times–there is no difference.


#15

I should mention too that this is also a problem with the juce demo.
also, I should mention this error message:
JUCE v1.46
JUCE Assertion failure in juce_amalgamated.cpp, line 15267


#16

Possible Clue:

Ok, I finally found a difference in the output of the juce demo program in the build directory where it works properly and any other directory where it doesn’t work properly. The difference is that there is an application file–it becomes the executable file when not properly functioning. Example of different output from the same code:

WORKS:
Current executable file: /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/JUCE/juceSRM/extras/juce demo/build/macosx/build/Release/jucedemo.app/Contents/MacOS/jucedemo
Current application file: /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/JUCE/juceSRM/extras/juce demo/build/macosx/build/Release/jucedemo.app

DOESN’T WORK:
Current executable file: /Users/smcguffee/BIN/jucedemo
Current application file: /Users/smcguffee/BIN/jucedemo

I am not familiar with having an “application” and an “executable.” All I know about so far are executables. What is going on with the “application” file? When I copy everything inside my application file (which is actually a directory) to another location, the program then works in other places (although still a few directories different than where I want it because it’s inside a few nested directories. Example:

cp -r build/Release/gview.app/* ~/BIN/
Now this works:
~/BIN/Contents/MacOS/gview
Why does it need “Contents/MacOS” in between its “executable” and it’s “application?” Is there somehow that I can change it to be the same path?

I should mention that this does solve my problem because I can make a link to it in the ~/BIN directory (which is in my path) and that now works. But I am curious as to what is going on.


#17

…not on anyone else’s machine, though! There must be something about the project that you’ve changed, or maybe your xcode SDK settings are just so broken that nothing is building with the right libraries…


#18

[quote=“smcguffee”]Possible Clue:

Ok, I finally found a difference in the output of the juce demo program in the build directory where it works properly and any other directory where it doesn’t work properly. The difference is that there is an application file–it becomes the executable file when not properly functioning. Example of different output from the same code:
.[/quote]

You’re missing something fundamental about apps on OSX.

An app is a wrapper around a UNIX executable. If you treat the .app to be a directory (which it is) and drill down into it, you’ll find a UNIX executable. However, that app directory is responsible for packaging all kinds of stuff that the executable needs to run as a Cocoa/Carbon UI application.

The simple take away is that you need to stop thinking about the UNIX file, and instead just deploy the .app directory.

When you double-click on an app in your applications folder, you’re just double-clicking on a .app dir that OSX’s finder knows to launch as an application.


#19

Ok, this is starting to make some sense now. So my only question is how do I control what the path name is between my *.app directory and my unix executable? In this case, I happened across one that worked that was a remnant of something that xcode had generated when I compiled a juce demo program. If I hadn’t had that directory structure already present, I would have never guessed such an arbitrary path name. I couldn’t find a string inside my unix executable that matches any part of the path name, so I’m at a loss for where this configuration is being set. Just to clarify, when I compile and link my unix executable, it’s in the path: /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GVIEW/build/Release/gview.app/Contents/MacOS/gview, inside the link command line. When I execute my command gview from the command line in that directory, it somehow knows that the application is in the directory: /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GVIEW/build/Release/gview.app. How is it deciding this from within the Unix executable? And how does the app know that /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GVIEW/build/Release/gview.app/Contents/MacOS/gview is the only path that the executable should run in? I guess what I’m really asking is where is the configuration stored that tells the app and the executable that there should be a “Contents/MacOS/” named directory structure between the app and the unix executable?


#20

I don’t understand why you’re asking these questions… XCode creates an app bundle for you, and you run it… You shouldn’t have to know or care about where things are inside it - just relax and don’t worry about it!