Why might extra-lib-dirs not work like LD_LIBRARY_PATH in stack?

bbarker :

--extra-lib-dirs should ostensibly function like LD_LIBRARY_PATH, but when used with stack exec I see different results:

$ stack --extra-lib-dirs=$MATLAB_PATH/bin/glnxa64 --extra-include-dirs=$MATLAB_PATH/extern/include --nix exec matlab-engine-test
/home/bebarker/workspace/haskell-matlab/.stack-work/install/x86_64-linux-nix/24c5769e9013838d87aa76fb4cdd10a09798b6904a6faa380de6fe6949e2c952/8.6.5/bin/matlab-engine-test: error while loading shared libraries: libmx.so: cannot open shared object file: No such file or directory

$ LD_LIBRARY_PATH=$MATLAB_PATH/bin/glnxa64 /home/bebarker/workspace/haskell-matlab/.stack-work/install/x86_64-linux-nix/24c5769e9013838d87aa76fb4cdd10a09798b6904a6faa380de6fe6949e2c952/8.6.5/bin/matlab-engine-test
matlab-engine-test: user error (engOpen)

LD_LIBRARY_PATH behaves as expected in this case (though clearly I have another unrelated issue to deal with there). Should I be looking for another option or am I using --extra-lib-dirs incorrectly?

Thomas M. DuBuisson :

I don't tend to use Stack, but in build systems the library path provided by command line flags is usually only passed to the linker. Observe (with main = print =<< lookupEnv "LD_LIBRARY_PATH"):

$ stack --extra-lib-dirs=/foopath/bin/glnxa64 --extra-include-dirs=/foopath/extern/include exec ./foo
Just ""

Compare with what you did second:

$ LD_LIBRARY_PATH=/foopath/bin/glnxa64 ./foo
Just "/foopath/bin/glnxa64"

Guess you like