GDC fails to link with GSL and fortran code

Andrew Brown via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Mar 17 17:07:31 PDT 2015


I'm getting some idea how difficult compilers could be to 
maintain across  distros, but I'm probably still a long way from 
knowing the true horror.

Thank you for taking the time to help me out, and then when my 
immediate problem was solved, more time to help me learn 
something.

I see there's a lot of discussion on these forums about the state 
of the documentation. Between googling historical questions here, 
and people's willingness to help on this forum, I've always found 
my answers. I think that's quite amazing.

Andrew

On Tuesday, 17 March 2015 at 21:00:46 UTC, Johannes Pfau wrote:
> Am Tue, 17 Mar 2015 12:13:44 +0000
> schrieb "Andrew Brown" <aabrown24 at hotmail.com>:
>
>> Thank you very much for your replies, I now have 2 solutions 
>> to my problem! Both compiling on a virtual machine running 
>> debian wheezy, and using gcc to do the linking produced 
>> executables that would run on the cluster.
>> 
>> Compiling with the verbose flags for linker and compiler 
>> produced the following output:
>> 
>> failed gdc attempt: http://dpaste.com/0Z5V4PV
>> 
>> successful dmd attempt: http://dpaste.com/0S5WKJ5
>> 
>> successful use of gcc to link: http://dpaste.com/0YYR39V
>> 
>> It seems a bit of a mess, with various libraries in various 
>> places. I'll see if I can get to the bottom of it, I think 
>> it'll be a learning experience.
>> 
>> Thanks again for the swift and useful help and guidance.
>> 
>> Andrew
>
> GCC's verbose output can indeed be quite confusing but if you 
> know
> what to look for it's possible to find some useful information 
> :-)
>
> In your case the linker messages hinted at a problem with libc. 
> And as
> there were only a few errors it's likely a version compatibility
> problem.
>
> If you search for libc.so in these logs you'll find this:
> Failed GDC:
> attempt to open /usr/lib/../lib64/libc.so succeeded
> opened script file /usr/lib/../lib64/libc.so
> opened script file /usr/lib/../lib64/libc.so
> attempt to open /lib64/libc.so.6 succeeded
> /lib64/libc.so.6
>
> GCC:
> attempt to
> open 
> /software/lib/gcc/x86_64-redhat-linux/4.9.1/../../../../lib64/libc.so
> succeeded opened script
> file 
> /software/lib/gcc/x86_64-redhat-linux/4.9.1/../../../../lib64/libc.so
> opened script
> file 
> /software/lib/gcc/x86_64-redhat-linux/4.9.1/../../../../lib64/libc.so
> attempt to open /software/lib64/libc.so.6
> succeeded /software/lib64/libc.so.6
>
> The binary gdc searches for libaries in the 'usual' places,
> including /usr/lib64. Your gcc doesn't search in /usr/lib64 but
> in /software. You seem to have an incompatible libc in 
> /usr/lib64
> which gets picked up by gdc. This is one reason why binary 
> compiler
> releases are difficult to maintain and we usually recommend to 
> compile
> gdc from source.
>
> DMD avoids this mess by simply calling the local gcc instead of 
> ld to
> link. GCC unfortunately doesn't support this and forces us to 
> always
> call the linker directly.



More information about the Digitalmars-d-learn mailing list