Thread overview
Error in Phobos linux.mak
Dec 03, 2004
Daniel Keep
Dec 03, 2004
John Reimer
Re: Error in Phobos linux.mak (and fix idea for dmd)
Dec 03, 2004
Daniel Keep
Dec 03, 2004
John Reimer
Dec 03, 2004
Thomas Kuehne
Dec 03, 2004
John Reimer
Dec 03, 2004
John Reimer
December 03, 2004
Hey.

I've just found that in the latest version of dmd (0.108 I think), libphobos.a is being built WITHOUT std.loader (which is very annoying since I'm trying to use it :P)

Anyway, I've attached a diff of dmd/src/phobos/linux.max that builds std.loader.  All I did was add loader.o to the list of standard object files, and make it a target.

	-- Daniel


December 03, 2004
On Fri, 03 Dec 2004 17:52:45 +1000, Daniel Keep wrote:

> Hey.
> 
> I've just found that in the latest version of dmd (0.108 I think), libphobos.a is being built WITHOUT std.loader (which is very annoying since I'm trying to use it :P)
> 
> Anyway, I've attached a diff of dmd/src/phobos/linux.max that builds std.loader.  All I did was add loader.o to the list of standard object files, and make it a target.
> 
> 	-- Daniel

Yes, I agree that it's annoying.  It's been that way for awhile. I
reported the same thing several months ago and nothing was done about it.
Maybe you'll have more success getting a response.  At least,
I sure hope so!

- John
December 03, 2004
Well, I think the reason it's not compiled in there by default is that it still doesn't allow you to directly use std.loader in linux.

From what I can tell, the problem is that dmd doesn't know HOW to compile support for std.loader in linux.  I manage to get around this by
manually doing the linking stage using gcc, and passing it -ldl along with all the usual stuff.  Although I haven't tested it thoroughly, so I don't know if there something else I've missed.

	-- Daniel

John Reimer wrote:
> On Fri, 03 Dec 2004 17:52:45 +1000, Daniel Keep wrote:
> 
> 
>>Hey.
>>
>>I've just found that in the latest version of dmd (0.108 I think), libphobos.a is being built WITHOUT std.loader (which is very annoying since I'm trying to use it :P)
>>
>>Anyway, I've attached a diff of dmd/src/phobos/linux.max that builds std.loader.  All I did was add loader.o to the list of standard object files, and make it a target.
>>
>>	-- Daniel
> 
> 
> Yes, I agree that it's annoying.  It's been that way for awhile. I
> reported the same thing several months ago and nothing was done about it. Maybe you'll have more success getting a response.  At least,
> I sure hope so!
> 
> - John
December 03, 2004
On Fri, 03 Dec 2004 21:01:38 +1000, Daniel Keep wrote:

> Well, I think the reason it's not compiled in there by default is that it still doesn't allow you to directly use std.loader in linux.
> 
>  From what I can tell, the problem is that dmd doesn't know HOW to
> compile support for std.loader in linux.  I manage to get around this by
> manually doing the linking stage using gcc, and passing it -ldl along
> with all the usual stuff.  Although I haven't tested it thoroughly, so I
> don't know if there something else I've missed.
> 
> 	-- Daniel

No, it works.  It's currently being used by two projects that I know of: Derelict and Claytek3D over at dsource.org.  You can compile and link std.loader in on the command line with your program, but you'll also have to remember to link the dynamic loader library that it uses: libdl.so. You do this just be doing a -ldl along with the other libraries when gcc is run or all at once with dmd using the -L-ldl option (passes -ldl on to the gcc link stage).

The other way is to make a quick modification to the makefile like you did and recompile phobos.  But then you now have to remember to add -L-ldl whenever you compile your programs because dmd only adds -lpthread and -lm libraries by default.  A quick way to fix this is to edit dmd.conf and add -L-ldl to the DFLAGS variable.  Then things should work correctly without having to worry about adding the flag whenever you compile your programs. But this should probably only be done with a libphobos.a that's been recompiled to include std.loader. The moment you upgrade to a newer version of dmd, remember that your libphobos will get overwritten.

I've had no success recompiling libphobos on linux primarily because the the recls lib breaks on my gcc 3.4.3.  I was surprised to see that there was C++ code polluting the d runtime library.... grrrr.

Later,

John R.


December 03, 2004
On Fri, 03 Dec 2004 21:01:38 +1000, Daniel Keep wrote:

> Well, I think the reason it's not compiled in there by default is that it still doesn't allow you to directly use std.loader in linux.
> 
>  From what I can tell, the problem is that dmd doesn't know HOW to
> compile support for std.loader in linux.  I manage to get around this by
> manually doing the linking stage using gcc, and passing it -ldl along
> with all the usual stuff.  Although I haven't tested it thoroughly, so I
> don't know if there something else I've missed.
> 
> 	-- Daniel

Sorry, you obviously had it figured out.  I missed the portion of your message that referred to -ldl....  I must have been reading to fast.

My apologies,

John
December 03, 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Reimer schrieb am Fri, 03 Dec 2004 04:30:26 -0800:
> I've had no success recompiling libphobos on linux primarily because the the recls lib breaks on my gcc 3.4.3.  I was surprised to see that there was C++ code polluting the d runtime library.... grrrr.

Hehe, it's working for me.

Use a versioned gcc/g++ in etc/c/recls/linux.mak.
gcc-3.4.1 and gcc-3.3.2 seem to work.
For all other parts I'm using gcc alias gcc-3.4.3.

It's an ugly kludge ...

Thomas


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.12 (GNU/Linux)

iD8DBQFBsF9c3w+/yD4P9tIRApW9AJ4swU4lfDWX2Wc/AR9I2HeoVzxrkACdHBDA
kprUWX0Yf6SSKfqVwNLsS8U=
=SxqO
-----END PGP SIGNATURE-----
December 03, 2004
On Fri, 03 Dec 2004 13:43:08 +0100, Thomas Kuehne wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John Reimer schrieb am Fri, 03 Dec 2004 04:30:26 -0800:
>> I've had no success recompiling libphobos on linux primarily because the the recls lib breaks on my gcc 3.4.3.  I was surprised to see that there was C++ code polluting the d runtime library.... grrrr.
> 
> Hehe, it's working for me.
> 
> Use a versioned gcc/g++ in etc/c/recls/linux.mak.
> gcc-3.4.1 and gcc-3.3.2 seem to work.
> For all other parts I'm using gcc alias gcc-3.4.3.
> 
> It's an ugly kludge ...
> 
> Thomas

Heh... smart idea.  I never thought of that.

Thanks for the tip.

- John