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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
