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

--Multipart=_Fri__16_Apr_2004_23_50_04_+0200_O85/W7t=2sV7eu/_
Content-Type: text/plain; charset=US-ASCII
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:

     If the first argument is NULL, dlopen() returns a handle on
     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 "LD_PRELOAD=plugin1.so ./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)

Thanks.

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/

--Multipart=_Fri__16_Apr_2004_23_50_04_+0200_O85/W7t=2sV7eu/_
Content-Type: application/octet-stream;
 name="tc.tar.gz"
Content-Disposition: attachment;
 filename="tc.tar.gz"
Content-Transfer-Encoding: base64

H4sIAAAAAAAAA+2WUYubQBDHfXU/xZBS0BDT3UQvkGsK1x4cBa8tpaW0FILo2myrq6x69Gjvu9dV
LwrNXfqQyz10fg/uujPOrMz+R/Ok+iZk4ZSh8WBQ6tKF59UjZQuP6pEy123GDoNpJ+qxBdV2xhbu
3PAebks9VVEGCsD4nqZX9/txVRxjQ8cl39b/WTtl04OfBFoX96St9876s/nitv6UzfQ6m3vuzKCH
3sgu/vP6PxEyTKqIw/OijEQ23bwg5CoTEelOwzquZGjpFZv8ImY7y5WQZWyNSl6UoB1KkUmIVZZC
99hXObJPyQ157NdD9jDQfxoIeXjxG/v1f8Jmvf5d1uifURf1fwR6/UdJHEqt/10todY70eej7wR6
AuNNIKOEn3a31rg9TmshRWm3vn/ZdL/Y2ogpYrCsNgysIEqynEtrNN1+jYpsNIH3H/zztX/25TP8
bucX/tuXZ75tw2oFbz76vk1Ms46gVKasJuwgWRO2uE67LBMYDXub7lNDb+vuXelEE6B3ZjVv++LT
vO5/k/uzNmkULyslgT5eqxzo/zL4wWOR8IPn2Kf/mUd7/Td2Nnc9/P4fgyBJlqCVDb3gSCP1dnka
EjMMwclap26J9M7L7YOdZ7EJFI/A+ZRMHIf/zDNVOtG1DFJRG+N3r1+Bc95cs0HKQRASJjyQy1oc
KYy1SefEHwkEQRAEQRAEQRAEQRAEQRAEQRAE+Qf+ACN97TcAKAAA

--Multipart=_Fri__16_Apr_2004_23_50_04_+0200_O85/W7t=2sV7eu/_--