Augmenting DYLD_LIBRARY_PATH

[StarCrunch]

Hi.

I need to be able to tell a plugin (a thin veneer over a much larger library written by others) where it can find some dynamic libraries installed separately. Through a lot of digging, I’ve found the LSEnvironment variable, where one can do basically

plist = { LSEnvironment = { DYLD\_LIBRARY\_PATH = "$DYLD\_LIBRARY\_PATH:/usr/local/lib:/usr/local/cuda/lib:/usr/local/cuda/nvvm/lib" } }

and for most keys the corresponding value will, indeed, be returned from later calls to os.getenv(“MY_ENV_VAR”).

However, in the case of DYLD_LIBRARY_PATH , Corona fails to load, so I figure its own value is getting stomped on. I’m thus led to assume that, outside of Bash scripts, the “$DYLD_LIBRARY_PATH:” part (also tried with curly braces) doesn’t actually resolve to the current value under that key.

Am I missing anything here? If not, what might be the least intrusive alternative? The vast majority of what I’ve dug up explains how to register variables in  ~/.bashrc , but ostensibly that’s irrelevant to GUI apps. Would ~/.MacOSX/environment.plist be the way to go?

I’m very green about OS X generally. Many of the sources I’ve been reading also seem to hint at abrupt divides among certain OS versions as far as how to do this sort of thing (Launch Control, etc.), and I’ve not had time to sift out what matters.

Thanks for any help!

[Perry_Clarke]

We don’t set  DYLD_LIBRARY_PATH when running the Simulator and it’s not something we support.  It has it’s uses but I usually end up wondering when I thought juggling bottles of kerosene over a campfile sounded like a good idea

I recommend studying the docs.  In Terminal:

man dyld

You can then debug library loading using the  DYLD_PRINT_* environment variables and by running the Simulator executable directly in a Terminal using:

DYLD\_LIBRARY\_PATH="$DYLD\_LIBRARY\_PATH:/usr/local/lib:/usr/local/cuda/lib:/usr/local/cuda/nvvm/lib" /Applications/CoronaSDK/Corona\ Simulator.app/Contents/MacOS/Corona\ Simulator -no-console YES

I took a quick look at what happens with your  DYLD_LIBRARY_PATH but the process hangs in a mysterious way trying to load something from libJPEG.a so I don’t know what’s happening.  Also,  DYLD_LIBRARY_PATH  isn’t normally set to the default value, the dynamic loader handles the default internally (unless you’ve set  DYLD_FALLBACK_LIBRARY_PATH which I doubt).

Your quickest way to a successful resolution of this is probably to copy (or symbolic link) your custom libraries into /usr/local/lib.

[StarCrunch]

The juggling act sounds like quite the show!

As far as the “mysterious hang”, in my case it was an issue with libpng: I think the same symbol mentioned here, though this suggests several libraries can be at fault. Following some of the advice in the first fixed the crashes, though after that I’m not sure anything happens.  At any rate, the plist / os.getenv() combo seems to have blacklisted that from LSEnvironment.

I’ll give the print variables thing a go once I’ve slept (I did try passing those through the plist, without any luck). Do these just need to be set to anything, or to 1, or what?

Anyhow, thanks for the help. I might have to pester the library authors a bit on this, too. 

[StarCrunch]

Well, as of a couple hours ago, I’ve got this past the first steps, though have by no means put it through its paces. Possibly related to the “fix” mentioned in my last post, a brew reinstall libpng seemed to be the final piece of the puzzle, though a missing “/opt/x11” (another of the “abrupt divides among certain OS versions”?) might have been contributing (at any rate, it was bringing down the SDK’s own samples).

I’ll keep the fallback path in mind for when I try to do CUDA (doesn’t look like my own GPU can do it).

Thanks!

[Perry_Clarke]

We don’t set  DYLD_LIBRARY_PATH when running the Simulator and it’s not something we support.  It has it’s uses but I usually end up wondering when I thought juggling bottles of kerosene over a campfile sounded like a good idea

I recommend studying the docs.  In Terminal:

man dyld

You can then debug library loading using the  DYLD_PRINT_* environment variables and by running the Simulator executable directly in a Terminal using:

DYLD\_LIBRARY\_PATH="$DYLD\_LIBRARY\_PATH:/usr/local/lib:/usr/local/cuda/lib:/usr/local/cuda/nvvm/lib" /Applications/CoronaSDK/Corona\ Simulator.app/Contents/MacOS/Corona\ Simulator -no-console YES

I took a quick look at what happens with your  DYLD_LIBRARY_PATH but the process hangs in a mysterious way trying to load something from libJPEG.a so I don’t know what’s happening.  Also,  DYLD_LIBRARY_PATH  isn’t normally set to the default value, the dynamic loader handles the default internally (unless you’ve set  DYLD_FALLBACK_LIBRARY_PATH which I doubt).

Your quickest way to a successful resolution of this is probably to copy (or symbolic link) your custom libraries into /usr/local/lib.

[StarCrunch]

The juggling act sounds like quite the show!

As far as the “mysterious hang”, in my case it was an issue with libpng: I think the same symbol mentioned here, though this suggests several libraries can be at fault. Following some of the advice in the first fixed the crashes, though after that I’m not sure anything happens.  At any rate, the plist / os.getenv() combo seems to have blacklisted that from LSEnvironment.

I’ll give the print variables thing a go once I’ve slept (I did try passing those through the plist, without any luck). Do these just need to be set to anything, or to 1, or what?

Anyhow, thanks for the help. I might have to pester the library authors a bit on this, too. 

[StarCrunch]

Well, as of a couple hours ago, I’ve got this past the first steps, though have by no means put it through its paces. Possibly related to the “fix” mentioned in my last post, a brew reinstall libpng seemed to be the final piece of the puzzle, though a missing “/opt/x11” (another of the “abrupt divides among certain OS versions”?) might have been contributing (at any rate, it was bringing down the SDK’s own samples).

I’ll keep the fallback path in mind for when I try to do CUDA (doesn’t look like my own GPU can do it).

Thanks!