• John Reimer (10/10) Jul 18 2004 It appears that std.loader is not compiled into the current linux versio...
• John Reimer (4/12) Jul 18 2004 Ahh... nevermind. Seems that I have to link to the libdl.so library (the
• Matthew (3/15) Jul 18 2004 I have no idea. That's a W Q. ;(

John Reimer <brk_6502 NO_S_PAM.yahoo.com> writes:

It appears that std.loader is not compiled into the current linux version
of phobos even though it is in the win32 version.  Why is this?

I tried compiling the linux version as a standalone with
-version=TestMain and -version=Linux, but for some reason the
linux c functions dlopen, dlclose, dlsym, and dlerror are reported
undefined in the gcc link stage.  These are part of Linux, so why can't
the linker find these symbols (they are declared extern (C) within
loader.d)?

Later,

John 

John Reimer <brk_6502 NO_S_PAM.yahoo.com> writes:

On Sun, 18 Jul 2004 15:29:20 -0700, John Reimer wrote:

 It appears that std.loader is not compiled into the current linux version
 of phobos even though it is in the win32 version.  Why is this?
 
 I tried compiling the linux version as a standalone with -version=TestMain
 and -version=Linux, but for some reason the linux c functions dlopen,
 dlclose, dlsym, and dlerror are reported undefined in the gcc link stage. 
 These are part of Linux, so why can't the linker find these symbols (they
 are declared extern (C) within loader.d)?

Ahh... nevermind. Seems that I have to link to the libdl.so library (the
dynamic loader) with an -ldl switch on the gcc commandline.

The first question still stands however.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"John Reimer" <brk_6502 NO_S_PAM.yahoo.com> wrote in message
news:pan.2004.07.18.22.45.10.708085 NO_S_PAM.yahoo.com...
 On Sun, 18 Jul 2004 15:29:20 -0700, John Reimer wrote:

 It appears that std.loader is not compiled into the current linux version
 of phobos even though it is in the win32 version.  Why is this?

 I tried compiling the linux version as a standalone with -version=TestMain
 and -version=Linux, but for some reason the linux c functions dlopen,
 dlclose, dlsym, and dlerror are reported undefined in the gcc link stage.
 These are part of Linux, so why can't the linker find these symbols (they
 are declared extern (C) within loader.d)?

 Ahh... nevermind. Seems that I have to link to the libdl.so library (the
 dynamic loader) with an -ldl switch on the gcc commandline.

 The first question still stands however.

I have no idea. That's a W Q. ;(