Re: Shell function and LD_LIBRARY_PATH

[Paul Smith]

On Sun, 2019-01-20 at 19:32 +0000, Mohammad Akhlaghi wrote:
> Since I couldn't find any mention of this in in the manual, I wanted to 
> see if this removal of LD_LIBRARY_PATH from the $(shell) function is 
> intentional or if its a bug?

It is not the case that LD_LIBRARY_PATH is removed by the $(shell...)
function.

What is true is that variables marked as exported in the makefile are
not exported to the $(shell...) function: they are only exported to
recipes.  This is a VERY long-standing behavior (basically, GNU make
has always worked that way since the export directive was added in the
early 1990's).

See for example: https://savannah.gnu.org/bugs/?10593

Usually the solution is to add the variable assignment into the shell
function invocation, but since you need this variable to start the
shell itself that's not possible here.

However:

> In Make, I have also exported `LD_LIBRARY_PATH', so my Bash can find
> the proper version of libreadline to link with.

this is not really right.  Setting LD_LIBRARY_PATH is a bad idea in
general.  It can wreak all sorts of havoc because it applies to  all
programs not just one program.

If a program must have LD_LIBRARY_PATH the right way to handle it is to
use a shell script wrapper for that binary that sets up the environment
then exec's it.  For example:

  mv bash bash-real
  cat >bash <<'EOF'
  #!/bin/sh
  export 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/home/user/.local/lib
  exec bash-real "$@"
  EOF
  chmod 755 bash

Now running bash should "work".  While this is great for SOME programs,
even this is really not a good idea for a shell because the entire
point of shell is to invoke other programs, and this passes
LD_LIBRARY_PATH to all of them.

What you should do is configure bash's runtime lookup path to look in
the right place by default using RPATH at link time, so you don't need
to set LD_LIBRARY_PATH in the first place.