Can't install DATES

[batelz]

Hi,

I'm just starting out, trying to build DATES.
When running make install, I get the following error:

cc -L/home/lilyag/Documents/OpenBLAS/lib/ -L/home/lilyag/Documents/gsl2.3/lib/  -L/home/lilyag/Documents/fftw-3.3.8/lib/  dates_expfit.o nicklib regsubs.o fitexp.o gslfit.o  -lm -lgsl -lblas -lfftw3 ./nicksrc/libnick.a   -o dates_expfit
/usr/bin/ld: nicklib(strsubs.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: nicklib(vsubs.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: nicklib(getpars.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: nicklib(xsearch.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: nicklib(sortit.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ./nicksrc/libnick.a(linsubs.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ./nicksrc/libnick.a(statsubs.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ./nicksrc/libnick.a(gds.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
make: *** [<builtin>: dates_expfit] Error 1

I tried changing the Makefile and add an -fPIE option -- the problem persists.
When I added a -no-pie option, the software was indeed built, but then I get another error when actually running the software:

cd ../example
./dates -p ../example/par.dates >"out"

grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
output should be POP.out ::
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
grabpars: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
output should be POP.out ::

I tried installing several gsl versions (2.3, 2.5 as requested, 2.7) and also tried installing and building in a Linux core computer as well as on an Ubuntu VM.
I keep getting to this stage where DATES is asking for libgsl.so.19, which I don't have in any of my folders. what I do have is lobgsl.so and libgsl.so.23.

Any idea what's the problem?

Thanks,
Batel

[vicbp1]

Hi, I am having the same problem, any advice?

[bodkan]

In case other people run into this error in the future, I just had this issue as well and found a quick hack around it.

1. Locating libgsl.so.* on my system (some corporate level RedHat RHEL system my university uses) showed that the required libgsl.so.19 is indeed missing but other versions are present:

$ find / -name "libgsl.so*" 2>/dev/null
/usr/lib64/libgsl.so.23
/usr/lib64/libgsl.so.23.1.0
/usr/lib64/libgsl.so
[...]

I suspect it's not enough that GSL is present but a precise version is assumed by Dates? No idea.

2. Symlink the libgsl.so.23 (or whichever is available on your system in the output above) that's present to a "fake" libgsl.so.19 in the same location:

If you have sudo sysadmin rights:

sudo ln -s /usr/lib64/libgsl.so.23 /usr/lib64/libgsl.so.19

After that Dates runs without problems.

If you don't have sysadmin rights:

cd $HOME # just an example
ln -s /usr/lib64/libgsl.so.23 libgsl.so.19 # there's no sudo here, so this symlinks into $HOME
export LD_LIBRARY_PATH=$HOME:$LD_LIBRARY_PATH # add $HOME to $LD_LIBRARY_PATH

After that Dates runs without problems. But note that export is only valid for the current terminal session, so you will have to do this every time you want to run Dates. Of course, you can also set $LD_LIBRARY_PATH in your ~/.bashrc or something.