Subject: Behavior of dlopen(NULL, 0)
To: None <>
From: Julio M. Merino Vidal <>
List: tech-userlevel
Date: 04/16/2004 23:50:04
This is a multi-part message in MIME format.

Content-Transfer-Encoding: 7bit

Hi all,

yet another problem with GNOME stuff, this time exposed by evolution (if you
tried to use it, you may have noticed that the Settings dialog appears empty).

The problem itself is located in libglade2.  It does a dlopen(NULL, 0) to
query the global symbol table of the program, looking for functions whose
name is only known at runtime.  Many times, these functions are located in
the same program, or in libraries directly used by it (linked during build
time), so the problem does not appear.  However, these required functions
may also be located in libraries that are dlopen'ed, and not linked against
the program (as happens in evolution); here is where trouble comes.

Quoting our dlopen's manpage, I see:

     the global symbol object. This object provides access to all symbols from
     an ordered set of objects consisting of the original program image and
     any dependencies loaded during startup.

So, it's supposed to not resolve any references to symbols in dlopen'ed libs.
As you can imagine... Linux does it the other way around, and those symbols
resolve properly.

I've attached a test case program (very similar to the one used to detect
the gst-plugins bug) that shows this behavior.  It'll print a 0x0 under
NetBSD, and some memory address under Linux (you'll need to add -ldl to
build on it).

Buuut... if you execute it with " ./main" under NetBSD,
it will work as it does in Linux.

So my question is... which implementation is right? (if there is a standard
about this...)
Is it there an easy workaround, if we are wrong?  (what I have in mind now
is some non-trivial work on glib2... that I would like to avoid if possible)


Julio M. Merino Vidal <>
The NetBSD Project -

Content-Type: application/octet-stream;
Content-Disposition: attachment;
Content-Transfer-Encoding: base64