GDC fails to link with GSL and fortran code

Johannes Pfau via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Mar 16 12:22:17 PDT 2015


Am Mon, 16 Mar 2015 16:44:45 +0000
schrieb "Andrew Brown" <aabrown24 at hotmail.com>:

> Hi,
> 
> I'm trying to compile code which calls C and fortan routines from 
> D on the linux cluster at work. I've managed to get it to work 
> with all 3 compilers on my laptop, but LDC and GDC fail on the 
> cluster (though DMD works perfectly). I'm using the precompiled 
> compiler binaries on these systems, the cluster doesn't have the 
> prerequistites for building them myself and I don't have admin 
> rights.
> 
> For GDC the commands I run are:
> 
> gcc -c C_code.c Fortran_code.f
> gdc D_code.d C_code.o Fortran_code.f -lblas -lgsl -lgslcblas -lm 
> -lgfortran -o out
> 

You could try to do the linking with the local compiler:

gdc D_code.d
gcc D_code.o C_code.o Fortran_code.o -lgphobos2 -lpthread -lblas -lgsl
-lgslcblas -lm -L path/to/x86_64-gdcproject-linux-gnu/lib/

> The error messages are:
> 
> /software/lib64/libgsl.so: undefined reference to 
> `memcpy at GLIBC_2.14'
> /software/lib64/libgfortran.so.3: undefined reference to 
> `clock_gettime at GLIBC_2.17'
> /software/lib64/libgfortran.so.3: undefined reference to 
> `secure_getenv at GLIBC_2.17'
> collect2: error: ld returned 1 exit status
> 

Seems like the binary GDC toolchain somehow picks up a wrong libc. The
toolchains are built with GLIBC 2.14. But IIRC we don't ship the libc
in the binary packages (for native compilers) and it should pick up the
local libc. Please run gdc with the '-v' and '-Wl,--verbose' options and
post a link to the full output.

> I can remove the gsl messages by statically linking to libgsl.a, 
> but this doesn't solve the gfortran issues.
> 
> If anyone knows a way round these issues, I'd be very grateful. 
> I'd also eventually like to find a way to easily share linux 
> biniaries with people, so they can use this code without these 
> kinds of headaches. If anyone has any advice for making this 
> portable, that would also help me out a lot.
> 

Usually the best option is to compile on old linux systems. Binaries
often run on newer systems but not on older ones. You could setup
debian wheezy or an older version in a VM or using docker.

Or you use docker.io ;-) I personally think the docker approach is kind
of overkill but avoiding compatibility issues is one of docker's main
selling points.


More information about the Digitalmars-d-learn mailing list