digitalmars.D.learn - Unresolvable references to dlopen, dlclose etc
- Mafi (14/14) Dec 05 2013 I am on fresh install of Linux Mint 16 64bit and I tried to
- Mafi (4/18) Dec 06 2013 Could at least somebody approve they have read it? Maybe I did
- Jacob Carlborg (5/17) Dec 06 2013 You can compile with the verbose flag, -v, to make sure it links as you
- Mafi (10/13) Dec 06 2013 Thank you! This has helped and I linked my program. As it turned
- Jacob Carlborg (7/17) Dec 06 2013 I would say that linking order shouldn't matter. But for some reason it
- Mafi (12/35) Dec 07 2013 So after some tweaking I made it work. Specfying the libpath with
- Mike Parker (6/23) Dec 08 2013 This is how the gcc linker works. It always causes confusion when people...
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!
Dec 05 2013
"Mafi" <mafi example.org>
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.
Dec 06 2013
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
Dec 06 2013
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.
Dec 06 2013
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
Dec 06 2013
On Friday, 6 December 2013 at 16:54:14 UTC, Jacob Carlborg wrote:On 2013-12-06 14:25, Mafi wrote: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!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.
Dec 07 2013
On 12/8/2013 6:12 AM, Mafi wrote:On Friday, 6 December 2013 at 16:54:14 UTC, Jacob Carlborg wrote: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.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!
Dec 08 2013