lmi
[Top][All Lists]
Advanced

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

Re: [lmi] LD_LIBRARY_PATH


From: Vadim Zeitlin
Subject: Re: [lmi] LD_LIBRARY_PATH
Date: Sat, 26 Sep 2020 22:57:19 +0200

On Sat, 26 Sep 2020 19:14:31 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2018-11-16 01:44, Vadim Zeitlin wrote:
GC> > On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> 
GC> [...some error messages...]
GC> 
GC> >  The only thing I can think of is that your LD_LIBRARY_PATH is not
GC> > exported, which could well be the case if you hadn't used it before. So
GC> > please try either
GC> > 
GC> >   $ export LD_LIBRARY_PATH
GC> >   $ ./lmi_cli_shared
GC> > 
GC> > or, as I typically do
GC> > 
GC> >   $ LD_LIBRARY_PATH=/opt/lmi/src/build/lmi/Linux/gcc/native 
./lmi_cli_shared
GC> 
GC> The message I just posted contained these two commands:
GC> 
GC> /opt/lmi/src/lmi[0]$LD_LIBRARY_PATH=: make $coefficiency cli_tests 2>&1 
|less -S
GC> 
GC> [...which AFAICT is kind of like
GC>   PATH=$PATH:. ./some_program
GC> and seems like a joke that shouldn't be repeated often...]
GC> 
GC> /opt/lmi/src/lmi[0]$lmipath=/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship; 
export LD_LIBRARY_PATH=$lmipath; $lmipath/lmi_cli_shared --accept 
--data_path=/opt/lmi/data --selftest
GC> 
GC> Really, you typically would type all that?

 Well, as shown above, I don't use export, which is slightly shorter (and
also doesn't pollute the environment). But yes, I often do something like
"LD_LIBRARY_PATH=lib ./bin/foo" because rpath is not always set or not
always set compatibly with the uninstalled files layout.

 If this is too much typing, it's always possible to define a shell script
or function to do it. FWIW libtool produces such scripts automatically by
default, which is why running lmi built with autotools doesn't require any
such manipulations: you're actually running the wrapper script and not the
real binary. As many other libtool features, this one is not well suited to
MSW, but works just fine under Unix.

GC> Or, more typically, you'd user 'rpath' to avoid all that typing?
GC> Debian discourages it:
GC>   https://wiki.debian.org/RpathIssue
GC> but I think that's because they distribute a vast number of
GC> programs that people may want to move around. There aren't a lot
GC> of customers for x86_64-pc-linux-gnu lmi builds, at least not yet,
GC> so I don't have Debian's worries.

 I definitely think lmi should set rpath to $ORIGIN/../lib, so that the
installed programs could find the installed libraries. This wouldn't help
with the uninstalled versions, however.

 Regards,
VZ

Attachment: pgpiBVEkBaC8R.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]