I am on fresh install of Linux Mint 16 64bit and I tried to compile some D code I have writen and I have problems ("Hello World" works btw). I uses Derelict (v2) and I have successfully compiled/linked/rurn my program on Windows 7 64bit. But on Linux I get errors about unresolved references to dlopen, dlclose etc. although I am linking against libdl (ld finds the so; I checked the verbose output).

Interestingly libdl.so is empty by nm. I found the symbols in libc.

I am compiling everything from scratch with the newest dmd (2.064.2 that is) with -m64 in my dmd.conf (doesn't work without either). I have posted on the Derelict forums (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't think it is a Derelict specific problem. Pleas help me!

On Thursday, 5 December 2013 at 19:20:16 UTC, Mafi wrote:
> I am on fresh install of Linux Mint 16 64bit and I tried to compile some D code I have writen and I have problems ("Hello World" works btw). I uses Derelict (v2) and I have successfully compiled/linked/rurn my program on Windows 7 64bit. But on Linux I get errors about unresolved references to dlopen, dlclose etc. although I am linking against libdl (ld finds the so; I checked the verbose output).
>
> Interestingly libdl.so is empty by nm. I found the symbols in libc.
>
> I am compiling everything from scratch with the newest dmd (2.064.2 that is) with -m64 in my dmd.conf (doesn't work without either). I have posted on the Derelict forums (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't think it is a Derelict specific problem. Pleas help me!

Could at least somebody approve they have read it? Maybe I did the installation wrong. I don't the slightest idea what to do. I am already trying for days.

On 2013-12-05 20:20, Mafi wrote:
> I am on fresh install of Linux Mint 16 64bit and I tried to compile some
> D code I have writen and I have problems ("Hello World" works btw). I
> uses Derelict (v2) and I have successfully compiled/linked/rurn my
> program on Windows 7 64bit. But on Linux I get errors about unresolved
> references to dlopen, dlclose etc. although I am linking against libdl
> (ld finds the so; I checked the verbose output).
>
> Interestingly libdl.so is empty by nm. I found the symbols in libc.
>
> I am compiling everything from scratch with the newest dmd (2.064.2 that
> is) with -m64 in my dmd.conf (doesn't work without either). I have
> posted on the Derelict forums
> (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't
> think it is a Derelict specific problem. Pleas help me!

You can compile with the verbose flag, -v, to make sure it links as you expect it to. The linking command will be at the bottom of the output.

-- 
/Jacob Carlborg

> You can compile with the verbose flag, -v, to make sure it links as you expect it to. The linking command will be at the bottom of the output.

Thank you! This has helped and I linked my program. As it turned out dmd invoked gcc to link and it supplied my -ldl argument first! I copy-pasted that command into a shell and moved the -ldl to the very end and it worked.

How do instruct dmd to do the same? As far as I understand the problem is that I specified the full path to the Derelict lib files by hand for each lib instead of using -L and -l. Libraries specifed like that are put after the gilen linker flags and before the buitlin ones (-lphobos etc). Is this a bug or is there any reason for dmd's behavior? It seems very wrong to me.

On 2013-12-06 14:25, Mafi wrote:

> Thank you! This has helped and I linked my program. As it turned out dmd
> invoked gcc to link and it supplied my -ldl argument first! I
> copy-pasted that command into a shell and moved the -ldl to the very end
> and it worked.
>
> How do instruct dmd to do the same? As far as I understand the problem
> is that I specified the full path to the Derelict lib files by hand for
> each lib instead of using -L and -l. Libraries specifed like that are
> put after the gilen linker flags and before the buitlin ones (-lphobos
> etc). Is this a bug or is there any reason for dmd's behavior? It seems
> very wrong to me.

I would say that linking order shouldn't matter. But for some reason it does. This not really my area of expertise but I know that others have had the same problem. You can try and search the newsgroups for linking order related problems.

-- 
/Jacob Carlborg

On Friday, 6 December 2013 at 16:54:14 UTC, Jacob Carlborg wrote:
> On 2013-12-06 14:25, Mafi wrote:
>
>> Thank you! This has helped and I linked my program. As it turned out dmd
>> invoked gcc to link and it supplied my -ldl argument first! I
>> copy-pasted that command into a shell and moved the -ldl to the very end
>> and it worked.
>>
>> How do instruct dmd to do the same? As far as I understand the problem
>> is that I specified the full path to the Derelict lib files by hand for
>> each lib instead of using -L and -l. Libraries specifed like that are
>> put after the gilen linker flags and before the buitlin ones (-lphobos
>> etc). Is this a bug or is there any reason for dmd's behavior? It seems
>> very wrong to me.
>
> I would say that linking order shouldn't matter. But for some reason it does. This not really my area of expertise but I know that others have had the same problem. You can try and search the newsgroups for linking order related problems.

So after some tweaking I made it work. Specfying the libpath with -L-L and the actual -L-l invokes gcc correctly. But the other behavior is still odd for me. I mean invoking dmd with

dmd myprog.d /path/to/libSomething.a -L[Linkerflags]

links with

gcc myprog.o [Linkerflags] /path/to/libSomething.a [Phobos]

you must

dmd myprog.d -L-L/path/to/ -l-lSomething

and hope the file name has the format libName.a .

But why? Both are objects. Why seperate them? For me there is no reason to ever want this order!

On 12/8/2013 6:12 AM, Mafi wrote:
> On Friday, 6 December 2013 at 16:54:14 UTC, Jacob Carlborg wrote:

>>
>> I would say that linking order shouldn't matter. But for some reason
>> it does. This not really my area of expertise but I know that others
>> have had the same problem. You can try and search the newsgroups for
>> linking order related problems.
>
> So after some tweaking I made it work. Specfying the libpath with -L-L
> and the actual -L-l invokes gcc correctly. But the other behavior is
> still odd for me. I mean invoking dmd with
>
> dmd myprog.d /path/to/libSomething.a -L[Linkerflags]
>
> links with
>
> gcc myprog.o [Linkerflags] /path/to/libSomething.a [Phobos]
>
> you must
>
> dmd myprog.d -L-L/path/to/ -l-lSomething
>
> and hope the file name has the format libName.a .
>
> But why? Both are objects. Why seperate them? For me there is no reason
> to ever want this order!

This is how the gcc linker works. It always causes confusion when people first encounter it. And even for people who have experience with it, there are corner cases where it's not always obvious that link order was the cause of an error. Google for "gcc link order" and you'll likely find some useful reading somewhere.