2

I am trying to install and run the program Dsuite. To do so, I had to install a newer version of gcc locally (as I do not have root/super user privileges.) I did this with the following commands.

cd /scratch/wdavis/Tools/source/gcc-4.9.4/

./contrib/download_prerequisites

cd /scratch/wdavis/Tools/gcc/

/scratch/wdavis/Tools/source/gcc-4.9.4/configure --prefix /scratch/wdavis/Tools/local/ --disable-multilib

make bootstrap-lean

make install

Everything seemed to work. Then I started on DSuite.

git clone https://github.com/millanek/Dsuite.git

cd Dsuite/

cd utils/

python3 setup.py install --user --prefix=

cd ../

I had to edit the Makefile to tell it where to find the correct version of g++ (/scratch/wdavis/Tools/local/bin/g++). Then I called make. Everything seemed to work. However, DSuite gave the following error:

Dsuite: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by Dsuite)`

I found two answers here and here that suggested "You can try building with -L/usr/local/lib64, and running with LD_LIBRARY_PATH=/usr/local/lib64 (if necessary).

export LD_LIBRARY_PATH=/scratch/wdavis/Tools/local/lib64/ Let me run Dsuite. However, make -L/scratch/wdavis/Tools/local/lib64/ did not work, i.e., Dsuite gave the same error after rebuilding it.

My questions then are:

  1. How to build a program such that when it is run, the dynamic linker will look in the correct directory for the libraries?

  2. What would happen if I run export LD_LIBRARY_PATH=/scratch/wdavis/Tools/local/lib64/, set up Dsuite to run, and then go on to run other programs without resetting LD_LIBRARY_PATH?

  3. How do I reset LD_LIBRARY_PATH?

Thanks in advance.

2
  • To add a 4th question: In the future, how would I avoid this problem? – wjdavis90 May 19 at 19:32
  • For those who stumble upon this in the future, a work around for the error without setting LD_LIBRARY_PATH for everything is to set a new screen then export LD_LIBRARY_PATH=/scratch/wdavis/Tools/local/lib64/ then leave screen -r. Dsuite will run with no problem and one is able to run other programs without worry they'll get hung up on the new LD_LIBRARY_PATH. – wjdavis90 May 20 at 14:44
1

make -L/scratch/wdavis/Tools/local/lib64/ is wrong.

-L is a flag for GCC and linker (e.g. ld), not make.

You should export this via export CFLAGS or CXXFLAGS depending on the language of the app. And maybe export it via LDFLAGS - it all depends how the app is built and linked, you can use GCC or ld to compile the final binary/library.

E.g.

export CFLAGS="-L/scratch/wdavis/Tools/local/lib64/"
export CXXFLAGS="-L/scratch/wdavis/Tools/local/lib64/"
export LDFLAGS="-L/scratch/wdavis/Tools/local/lib64/"
./configure && make

LD_LIBRARY_PATH is a flag for glibc and it's meant for executing apps, not linking them.

Please read the docs carefully. It's all in there, man gcc, man ld, man ld.so

  1. man bash

You do unset VAR_NAME

1
  • 1. export CFLAGS="-L/scratch/wdavis/Tools/local/lib64/" export CXXFLAGS="-L/scratch/wdavis/Tools/local/lib64/" export LDFLAGS="-L/scratch/wdavis/Tools/local/lib64/" nor setting -L/scratch/wdavis/Tools/local/lib64/ in the Makefile changed anything. Dsuite throws the same error. 2. Yes? I'm trying to get Dsuite to execute without an error. 3. Thanks! – wjdavis90 May 19 at 20:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.