Re: Comments on the Mac installation instructions on the wiki

[Paul Kienzle]

On Apr 13, 2007, at 6:14 PM, Thomas Treichl wrote:

> Paul Kienzle schrieb:
> > On Apr 8, 2007, at 3:21 PM, Marius Schamschula wrote:
> > > Paul,
> > > On Apr 8, 2007, at 1:59 PM, Paul Kienzle wrote:
> > > > On Apr 8, 2007, at 11:40 AM, Marius Schamschula wrote:
> > > > > Paul,
> > > > >
> > > > > On Apr 8, 2007, at 10:11 AM, Paul Kienzle wrote:
> > > > > > You could also build octave as an app.
> > > > > I've looked at this approach in the past. This has been done for 
> > > > > Gimp and several other open source packages. The problem is the 
> > > > > Voodoo associated with the DYLD_LIBRARY_PATH. Setting the 
> > > > > environmental variable can cause problems. To build a self 
> > > > > contained app, you have to manually change the internal paths 
> > > > > after building such that everything is on a relative path (dylibs 
> > > > > are on absolute paths by default, run otool -L against a dylib). 
> > > > > The library names change every time a package is updated, so this 
> > > > > is very difficult to automate. Frankly, I hate messing with it, 
> > > > > just as much as Frameworks get in the way to a point where I'd 
> > > > > rather rebuild a library than build against a Framework installed 
> > > > > by the OS. I gave up on the app approach since I have things 
> > > > > working in the classical *NIX style on the command line.
> > > >
> > > > DYLD_LIBRARY_PATH worked for me when I tried it three years ago.
> > > I didn't say it doesn't work. However, you got to be very careful, 
> > > otherwise you can break any and all applications (i.e. something 
> > > akin to rm when used as -Rf from root - fortunately you can undo 
> > > this). I vaguely remember setting DYLD_LIBRARY_PATH for a particular 
> > > package, which worked, but most everything else didn't. Setting 
> > > DYLD_LIBRARY_PATH is a kludge, it should not be needed.
> > The environment variable will only affect the current shell.  By 
> > putting it in a script you restrict it so it won't break the rest of 
> > the system.  The only danger I can see is when the user runs a shell 
> > command from octave since it inherits the octave environment, but we 
> > should be able to remove DYLD_LIBRARY_PATH from the environment once 
> > octave is running, so even that danger is minimal.  Since all of this 
> > is happening inside an app, most users won't notice anything is being 
> > done.
> >         - Paul
>
> Paul, what exactly do you mean with:
>
>   > The only danger I can see is when the user runs a shell
>   > command from octave since it inherits the octave environment, 
> <snip>
>
> you have some sample for me to run out of the Octave.app?

DYLD_LIBRARY_PATH is inherited for all external applications that 
octave calls.  This includes makeinfo for help, various tools such as 
sed, the shell script, gnuplot, and others, as well as any commands 
users call with system().  I don't know if any of these are affected by 
you setting DYLD_LIBRARY_PATH.  I wouldn't expect them to be (you are 
including gnuplot in the dmg and all the others should  be found in the 
usual places according to DYLD_FALLBACK_LIBRARY_PATH), but I haven't 
tested it myself.

I haven't experienced Marius's problems with DYLD_LIBRARY_PATH, but 
presumably they would appear if he were using Octave as the shell.

- Paul