gabriel rosenkoetter on Sun, 6 Jan 2002 22:30:15 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: LD_LIBRARY_PATH (was: Re: [PLUG] Update on My Debian Progress)


On Sun, Jan 06, 2002 at 04:11:26AM +0100, Jeff Abrahamson wrote:
> Wow, thanks.

No trouble. Just one of my little crusades. ;^>

> I got into LD_LIBRARY_PATH from two sources: config instructions from
> sysadmins and/or colleagues and configure.

Well. Many smart people have been taken in by the convenience of
LD_LIBRARY_PATH without understanding he dangers.

> The first comes up in context like oracle, where I'm told to set
> 
>     PATH=$PATH:$ORACLE_HOME/bin,
> 
> then set
> 
>     LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib.
> 
> This sort of thing. I never bothered to test to see if it was really
> necessary, but the amount of wrapping I'd have to do as an individual
> user would be heinous.

Hrm. Oracle has a lot of binaries, huh?

The right way to fix that is just to install the Oracle binaries
somewhere that's *already* in users' PATHs (and same with the
libraries). If your sysadmin thinks he's hiding the Oracle stuff
from some users by not putting it in their path, he's clearly wrong.

> And, with everyone else doing it, any bug I had
> would get blamed on having a different env, so it wasn't worth
> bucking. (Already some people like to blame problems of non-csh users
> on the fact that they aren't using csh. They are heathens who don't
> understand the finer subtleties of unix, but heathens with power.)

Yep. Not much you can do about this, of course, if you're not in
control of the system.

Otoh, here's the wrapper script you'd need to write:

#!/bin/sh
ORACLE_HOME=<foo>
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ORACLE_HOME}/lib
export ORACLE_HOME LD_LIBRARY_PATH
${ORACLE_HOME}/bin/${0}

Then toss that in ${HOME}/bin named the same thing as one of
Oracle's binaries. Then sym link ${HOME}/bin/<all the other Oracle
binary names> to it. You're done.

Oh, and if you only have problems that you can fix yourself, then
you'll never get blamed for an alternative environment. :^>

> Anyway, several apps, can't tell you which right now, have emitted
> warnings about how I should be sure to set LD_LIBRARY_PATH or edit
> /etc/ld.conf.

As I said, whoever wrote their Makefile needs a beating with a
cluebat. If they're Makefile code is even remotely clean, you can
just go through putting -R$(PREFIX)/lib and -l$(PREFIX)/lib/$(TARGET)
in the right places. (There's also several other env variables that
control ld's behavior which you can set, and one of them might be
an extra path to compile into the binary, which would save the
Makefile hacking. That should be on the web page I mentioned in my
last post on this topic.)

Remember that having LD_LIBRARY_PATH set *while* compiling software
*will* make that software broken if it's used in an environment
without LD_LIBRARY_PATH set.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpxPn3YNVGAq.pgp
Description: PGP signature