[lmi] LD_LIBRARY_PATH [Was: Inchoate support for GNU/Linux builds with lmi makefiles]

[Greg Chicares]

On 2018-11-16 01:44, Vadim Zeitlin wrote:
> On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...some error messages...]

>  The only thing I can think of is that your LD_LIBRARY_PATH is not
> exported, which could well be the case if you hadn't used it before. So
> please try either
> 
>       $ export LD_LIBRARY_PATH
>       $ ./lmi_cli_shared
> 
> or, as I typically do
> 
>       $ LD_LIBRARY_PATH=/opt/lmi/src/build/lmi/Linux/gcc/native 
> ./lmi_cli_shared

The message I just posted contained these two commands:

/opt/lmi/src/lmi[0]$LD_LIBRARY_PATH=: make $coefficiency cli_tests 2>&1 |less -S

[...which AFAICT is kind of like
  PATH=$PATH:. ./some_program
and seems like a joke that shouldn't be repeated often...]

/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

Really, you typically would type all that?

> If this doesn't work, you should consider setting LD_TRACE_LOADED_OBJECTS
> or LD_DEBUG (see ld.so(8)), but normally it really, really should work
> because lmi makefiles don't do anything with rpath (they almost certainly
> should, but this is another story).

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