I've installed some stuff which have put their libraries in /usr/local/
lib.

Whats the best way to ensure these libraries are found at runtime?

1. create a ln for each of the files in /usr/local/lib
2. add /usr/local/lib to LD_LIBRARY_PATH

"BertieBigBollox@gmail.com" <BertieBigBollox@gmail.com> wrote in
news:1be35863-12cb-4eb0-94dc-2808b4f25013@s19g2000prg.googlegroups.co
m: 

> I've installed some stuff which have put their libraries in
> /usr/local/ lib.
> 
> Whats the best way to ensure these libraries are found at runtime?
> 
> 1. create a ln for each of the files in /usr/local/lib
> 2. add /usr/local/lib to LD_LIBRARY_PATH
> 

man crle

....Steve

-- 
Steve van der Burg
Technical Analyst, Information Services
London Health Sciences Centre
London, Ontario, Canada
Email: steve.vanderburg@lhsc.on.ca

"BertieBigBollox@gmail.com"  wrote:

> I've installed some stuff which have put their libraries in /usr/local/
> lib.
> 
> Whats the best way to ensure these libraries are found at runtime?
> 
> 1. create a ln for each of the files in /usr/local/lib
> 2. add /usr/local/lib to LD_LIBRARY_PATH

3. Use the -R flag appropriately for everything you compile that links to
these libraries.

On 2008-02-05 14:06:47 +0000, Marc <marc.glisse@gmail.com> said:

> "BertieBigBollox@gmail.com"  wrote:
> 
>> I've installed some stuff which have put their libraries in /usr/local/
>> lib.
>> 
>> Whats the best way to ensure these libraries are found at runtime?
>> 
>> 1. create a ln for each of the files in /usr/local/lib
>> 2. add /usr/local/lib to LD_LIBRARY_PATH
> 
> 3. Use the -R flag appropriately for everything you compile that links to
> these libraries.

That's the right solution; if you aren't able to relink things to use 
these libs then you should set LD_LIBRARY_PATH in wrapper scripts 
around those executables. Don't set LD_LIBRARY_PATH anywhere else, it 
is evil.

Cheers,

Chris

On Tue, 5 Feb 2008, BertieBigBollox@gmail.com wrote:

> I've installed some stuff which have put their libraries in /usr/local/
> lib.
> 
> Whats the best way to ensure these libraries are found at runtime?
> 
> 1. create a ln for each of the files in /usr/local/lib
> 2. add /usr/local/lib to LD_LIBRARY_PATH

3. Insist that the vendor compile them properly, using the -R
argument to set the runtime library search path.  Also, apps
should be installed under /opt, not /usr (which is reserved for
use by the OS).

-- 
Rich Teer, SCSA, SCNA, SCSECA, OGB member

CEO,
My Online Home Inventory

URLs: http://www.rite-group.com/rich
      http://www.linkedin.com/in/richteer
      http://www.myonlinehomeinventory.com

Chris Ridd <chrisridd@mac.com> writes:
> That's the right solution; if you aren't able to relink things to use
> these libs then you should set LD_LIBRARY_PATH in wrapper scripts
> around those executables. Don't set LD_LIBRARY_PATH anywhere else, it
> is evil.

It's pretty evil in wrapper scripts as well.  If your application does
anything "unusual" such as execing another process (e.g., forking off
a copy of "/usr/bin/lp" to print something), you'll likely blindly
pass along LD_LIBRARY_PATH, and cause trouble for that new process.

Just don't do it.

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 2008-02-05 18:21:02 +0000, James Carlson <james.d.carlson@sun.com> said:

> Chris Ridd <chrisridd@mac.com> writes:
>> That's the right solution; if you aren't able to relink things to use
>> these libs then you should set LD_LIBRARY_PATH in wrapper scripts
>> around those executables. Don't set LD_LIBRARY_PATH anywhere else, it
>> is evil.
> 
> It's pretty evil in wrapper scripts as well.  If your application does
> anything "unusual" such as execing another process (e.g., forking off
> a copy of "/usr/bin/lp" to print something), you'll likely blindly
> pass along LD_LIBRARY_PATH, and cause trouble for that new process.
> 
> Just don't do it.

Agreed.

I've heard of a tool on Linux which edits an ELF executable's RPATH 
section, I daresay it'll build on Solaris with a bit of effort. I'm not 
sure that it is more or less vile than setting LD_LIBRARY_PATH though 
:-)

Cheers,

Chris

Chris Ridd  wrote:

> I've heard of a tool on Linux which edits an ELF executable's RPATH 
> section, I daresay it'll build on Solaris with a bit of effort.

There are several such tools, but they usually don't offer to increase
the size of your rpath, which means that you can do as well by editing
the file and replacing the old rpath with a new one (of exactly the same
size, or smaller and replacing the next character by \0).

For solaris, you could look at:
http://blogs.sun.com/ali/entry/introducing_elfedit_a_tool_for

James Carlson  wrote:

> It's pretty evil in wrapper scripts as well.  If your application does
> anything "unusual" such as execing another process (e.g., forking off
> a copy of "/usr/bin/lp" to print something), you'll likely blindly
> pass along LD_LIBRARY_PATH, and cause trouble for that new process.

You could also use LD_CONFIG and a special ld.config to limit the damage
to one library name. Or only use LD_LIBRARY_PATH pointing to directories
with very few libraries, for the same reason. But (free?)bsd is much
better there, iirc you can specify in a configuration file for each
library what should be loaded from where, *depending on the
program/library that requested it*.

On Tue, 5 Feb 2008 05:50:01 -0800 (PST), BertieBigBollox@gmail.com
   <BertieBigBollox@gmail.com> wrote:
> I've installed some stuff which have put their libraries in /usr/local/
> lib.
>
> Whats the best way to ensure these libraries are found at runtime?
>
> 1. create a ln for each of the files in /usr/local/lib
> 2. add /usr/local/lib to LD_LIBRARY_PATH

Number one is bad (and I presume that you mean a link from files in
/usr/lib to /usr/local/lib). Number two is not much better.

I'll suggest a number three:

3. If you can, build the app yourself, and set the RPATH to point to the
right directory. The app then won't need any band-aid to help it finds
its shared libs.

As a workaround if you can't build the app:

4. Write a wrapper shell script (or alias) that sets LD_LIBRARY_PATH.

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr

On 2008-02-05 19:02:56 +0000, Marc <marc.glisse@gmail.com> said:

> James Carlson  wrote:
> 
>> It's pretty evil in wrapper scripts as well.  If your application does
>> anything "unusual" such as execing another process (e.g., forking off
>> a copy of "/usr/bin/lp" to print something), you'll likely blindly
>> pass along LD_LIBRARY_PATH, and cause trouble for that new process.
> 
> You could also use LD_CONFIG and a special ld.config to limit the damage
> to one library name. Or only use LD_LIBRARY_PATH pointing to directories
> with very few libraries, for the same reason. But (free?)bsd is much
> better there, iirc you can specify in a configuration file for each
> library what should be loaded from where, *depending on the
> program/library that requested it*.

Could you use LD_PRELOAD to preload the libraries in the "wrong" location?

Cheers,

Chris

On Feb 5, 4:30=A0pm, Rich Teer <rich.t...@rite-group.com> wrote:
> On Tue, 5 Feb 2008, BertieBigBol...@gmail.com wrote:
> > I've installed some stuff which have put their libraries in /usr/local/
> > lib.
>
> > Whats the best way to ensure these libraries are found at runtime?
>
> > 1. create a ln for each of the files in /usr/local/lib
> > 2. add /usr/local/lib to LD_LIBRARY_PATH
>
> 3. Insist that the vendor compile them properly, using the -R
> argument to set the runtime library search path. =A0Also, apps
> should be installed under /opt, not /usr (which is reserved for
> use by the OS).


Hmm. My knowledge of compiling stuff on Solaris is not great I'm
afraid....

These are utilities downloaded from sunfreeware.com.

All I'm doing is following the instructions given which, in general,
state I need to do:-
=2E/configure
make
make install.

How would I introduce the -R argument?

How would I stop them installing in /usr/local but use /opt instead?

Is it the config.h file produced by ./configure?

On Feb 5, 8:54=A0pm, Paul Floyd <r...@127.0.0.1> wrote:
> On Tue, 5 Feb 2008 05:50:01 -0800 (PST), BertieBigBol...@gmail.com
> =A0 =A0<BertieBigBol...@gmail.com> wrote:
>
> > I've installed some stuff which have put their libraries in /usr/local/
> > lib.
>
> > Whats the best way to ensure these libraries are found at runtime?
>
> > 1. create a ln for each of the files in /usr/local/lib
> > 2. add /usr/local/lib to LD_LIBRARY_PATH
>
> Number one is bad (and I presume that you mean a link from files in
> /usr/lib to /usr/local/lib). Number two is not much better.

Why is number one bad? It works.... :-)

On Wed, 06 Feb 2008 02:07:55 -0800, BertieBigBollox@gmail.com wrote:

> Hmm. My knowledge of compiling stuff on Solaris is not great I'm
> afraid....

It looks like you will be learning.

> These are utilities downloaded from sunfreeware.com.

Get rid of them, all of them.  Install the free software from Sun:

http://www.sun.com/software/solaris/freeware/

> All I'm doing is following the instructions given which, in general,
> state I need to do:-
> ./configure

Try ./configure --help first.

> How would I introduce the -R argument?

From my ~/.bashrc:  -excuse the long line-

#export CC=/usr/sfw/bin/gcc
#export CXX=/usr/sfw/bin/g++
#export CFLAGS='-O2 -pipe -m32 -march=k8 -mtune=k8'

export CC=/opt/SUNWspro/bin/cc
export CXX=/opt/SUNWspro/bin/CC
export CFLAGS='-xO3 -m32 -xarch=native -mt'

export LDFLAGS='-L/opt/sfw/lib -R/opt/sfw/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/usr/X11/lib -R/usr/X11/lib -L/usr/openwin/lib -R/usr/openwin/lib'
export CXXFLAGS=$CFLAGS

The configure script generally reads these environmental values and
applies them to the resulting makefiles.

> How would I stop them installing in /usr/local but use /opt instead?

By using the --prefix= argument to ./configure.

> Is it the config.h file produced by ./configure?

Yes.

Dave Uhring wrote:
> On Wed, 06 Feb 2008 02:07:55 -0800, BertieBigBollox@gmail.com wrote:
>> How would I introduce the -R argument?

> export LDFLAGS='-L/opt/sfw/lib -R/opt/sfw/lib ... '

sometimes (not often, fortunately) I've seen sources that ignore your LDFLAGS.
In those cases you can also force the linker options by using LD_OPTIONS
or LD_RUN_PATH  (see "man ld", "ENVIRONMENT VARIABLES")

export LD_OPTIONS='-L/opt/sfw/lib -R/opt/sfw/lib ... '

../configure --prefix=/opt/local && make && make install

On Wed, 06 Feb 2008 09:27:36 -0500, Oscar del Rio wrote:

> sometimes (not often, fortunately) I've seen sources that ignore your
> LDFLAGS. In those cases you can also force the linker options by using
> LD_OPTIONS or LD_RUN_PATH  (see "man ld", "ENVIRONMENT VARIABLES")

Then there are the sources which use pkgconfig and completely ignore any 
such environmental values.  And making life more challenging for noobs 
are such fun things from Sun as (this is from nvb_81 and should have long 
ago been fixed):

/usr/sfw/lib/pkgconfig/gtk+.pc

Libs: -L${libdir} -lgtk

BertieBigBollox@gmail.com wrote:
> On Feb 5, 4:30 pm, Rich Teer <rich.t...@rite-group.com> wrote:
> 
>>On Tue, 5 Feb 2008, BertieBigBol...@gmail.com wrote:
>>
>>>I've installed some stuff which have put their libraries in /usr/local/
>>>lib.
>>
>>>Whats the best way to ensure these libraries are found at runtime?
>>
>>>1. create a ln for each of the files in /usr/local/lib
>>>2. add /usr/local/lib to LD_LIBRARY_PATH
>>
>>3. Insist that the vendor compile them properly, using the -R
>>argument to set the runtime library search path.  Also, apps
>>should be installed under /opt, not /usr (which is reserved for
>>use by the OS).
> 
> 
> 
> Hmm. My knowledge of compiling stuff on Solaris is not great I'm
> afraid....
> 
> These are utilities downloaded from sunfreeware.com.
> 
> All I'm doing is following the instructions given which, in general,
> state I need to do:-
> ./configure
> make
> make install.
> 
> How would I introduce the -R argument?
> 
> How would I stop them installing in /usr/local but use /opt instead?
> 
> Is it the config.h file produced by ./configure?

ISTR that the "configure" file takes a "help" argument which causes it 
to display a help file that tells you how to direct the placement of the 
executable file (among other things).

My fading memory tells me that it's something like:
../configure - -help

On Wed, 6 Feb 2008, BertieBigBollox@gmail.com wrote:

> These are utilities downloaded from sunfreeware.com.

I thought as much...

> How would I stop them installing in /usr/local but use /opt instead?

Probably the easiest way for you would be to download the apps you
want from www.blastwave.org instead of www.sunfreeware.com.  Blastwave's
packages put stuff where they're supposed to be (under /opt).

> Is it the config.h file produced by ./configure?

Usually it's the Makefile needs tweeking.

-- 
Rich Teer, SCSA, SCNA, SCSECA, OGB member

CEO,
My Online Home Inventory

URLs: http://www.rite-group.com/rich
      http://www.linkedin.com/in/richteer
      http://www.myonlinehomeinventory.com

Richard B. Gilbert wrote:
> BertieBigBollox@gmail.com wrote:
> 
>> On Feb 5, 4:30 pm, Rich Teer <rich.t...@rite-group.com> wrote:
>>
>>> On Tue, 5 Feb 2008, BertieBigBol...@gmail.com wrote:
>>>
>>>> I've installed some stuff which have put their libraries in /usr/local/
>>>> lib.
>>>
>>>
>>>> Whats the best way to ensure these libraries are found at runtime?
>>>
>>>
>>>> 1. create a ln for each of the files in /usr/local/lib
>>>> 2. add /usr/local/lib to LD_LIBRARY_PATH
>>>
>>>
>>> 3. Insist that the vendor compile them properly, using the -R
>>> argument to set the runtime library search path.  Also, apps
>>> should be installed under /opt, not /usr (which is reserved for
>>> use by the OS).
>>
>>
>>
>>
>> Hmm. My knowledge of compiling stuff on Solaris is not great I'm
>> afraid....
>>
>> These are utilities downloaded from sunfreeware.com.
>>
>> All I'm doing is following the instructions given which, in general,
>> state I need to do:-
>> ./configure
>> make
>> make install.
>>
>> How would I introduce the -R argument?
>>
>> How would I stop them installing in /usr/local but use /opt instead?
>>
>> Is it the config.h file produced by ./configure?
> 
> 
> ISTR that the "configure" file takes a "help" argument which causes it 
> to display a help file that tells you how to direct the placement of the 
> executable file (among other things).
> 
> My fading memory tells me that it's something like:
> ./configure - -help

usually, it is
../configure  --help
the relevant option is (usually also)
../configure --prefix=/opt/myowndirectory
and either add /opt/myowndirectory/bin or the like to your PATH
or make symbolic links of the executable files in a directory already in 
your path.

if you prefer to put everything in common directories,
just use
--prefix=/opt   (your files will the go in /opt/bin  /opt/lib etc...)
If you choose this lazy solution, you will most probably regret it
later, because it makes maintenance much harder.

On Wed, 6 Feb 2008 02:09:01 -0800 (PST), BertieBigBollox@gmail.com
   <BertieBigBollox@gmail.com> wrote:
>> > 1. create a ln for each of the files in /usr/local/lib
>> > 2. add /usr/local/lib to LD_LIBRARY_PATH
>
> Why is number one bad? It works.... :-)

What happens if you need two incompatible versions of a library on your
system? You can't put them both in /usr/lib.

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr

On Feb 6, 9:25=A0pm, Paul Floyd <r...@127.0.0.1> wrote:
> On Wed, 6 Feb 2008 02:09:01 -0800 (PST), BertieBigBol...@gmail.com
> =A0 =A0<BertieBigBol...@gmail.com> wrote:
>
> >> > 1. create a ln for each of the files in /usr/local/lib
> >> > 2. add /usr/local/lib to LD_LIBRARY_PATH
>
> > Why is number one bad? It works.... :-)
>
> What happens if you need two incompatible versions of a library on your
> system? You can't put them both in /usr/lib.
>
> A bientot
> Paul
> --
> Paul Floyd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://paulf.free.fr

Good point. Didnt think of that.