Bug 129031 - Portability issue: accessing symbols in shared objects via dlsym(3)
Summary: Portability issue: accessing symbols in shared objects via dlsym(3)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Konstantin Belousov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-21 00:10 UTC by Markus Hoenicka
Modified: 2008-11-29 22:48 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Hoenicka 2008-11-21 00:10:04 UTC
libdbi (http://libdbi.sourceforge.net) is a database abstraction layer provided as a shared object. libdbi uses dlopen() to load database engine drivers at runtime. Each of these drivers is linked against the client library of it's database engine:

app (linked to) libdbi (dlopens) driver (linked to) client library

Now libdbi is supposed to provide access to functions defined in the client libraries. To this end, dlsym is called with the function's name as the second argument. Unfortunately FreeBSD (and maybe other BSDs) differs from other systems in what may be passed to dlsym as the first argument:

If I pass the handle returned by dlopen() to dlsym(), the call fails.
If I pass RTLD_NEXT to dlsym(), the call succeeds.

If I try the same on other systems (OSX, Linux, Cygwin), the inverse is true:

If I pass the handle returned by dlopen() to dlsym(), the call succeeds.
If I pass RTLD_NEXT to dlsym(), the call fails.

Question is, is this a bug or a feature (in either system)? Are there better ways to arrive at a portable application than checking for the host type in configure?

How-To-Repeat: A test kit containing 4 source files and a Makefile is available here:

http://libdbi.sourceforge.net/downloads/dlsymtest.tar.gz

The kit builds straight on FreeBSD. To build it on Linux or other non-BSD systems, add -ldl in the Makefile as indicated by a comment.

To run the test app, use:

LD_LIBRARY_PATH=. ./myprog

The output on FreeBSD reads:

myint = 0xdeadbeef (3735928559)
==> entered myfunc()
==>     double = 3.141590
==>zlib version is 1.2.2
==> exiting myfunc()
dlsym() using dlopen handle failed: Undefined symbol "zlibVersion"
dlsym() using RTLD_NEXT succeeded

Note that the "driver" (myshared.so) uses zlibVersion() to retrieve the version number. However, the "library" (mylib.so) cannot access this function if the handle returned by dlopen() is used.

The output on Linux (Debian 4 using kernel 2.6.24) reads:
myint = 0xdeadbeef (3735928559)
==> entered myfunc()
==>     double = 3.141590
==>zlib version is 1.2.2
==> exiting myfunc()
dlsym() using dlopen handle succeeded
dlsym() using RTLD_NEXT failed: (null)
Comment 1 Remko Lodder freebsd_committer freebsd_triage 2008-11-21 08:45:13 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-standards

I think the standards group is a better place for this ticket.
Comment 2 Konstantin Belousov freebsd_committer freebsd_triage 2008-11-22 13:25:52 UTC
State Changed
From-To: open->feedback

I believe I fixed the issue long time ago. It should be so in the 
6.3 at least. Please confirm. 


Comment 3 Konstantin Belousov freebsd_committer freebsd_triage 2008-11-22 13:25:52 UTC
Responsible Changed
From-To: freebsd-standards->kib

Grab to watch the response.
Comment 4 Markus Hoenicka 2008-11-29 21:50:50 UTC
I've upgraded one of my systems to:

FreeBSD wutz.mininet 6.4-STABLE FreeBSD 6.4-STABLE #0: Sat Nov 29
13:59:50 CET 2008     markus@wutz.mininet:/usr/obj/usr/src/sys/WUTZ
i386

The output of the test program reads:

myint = 0xdeadbeef (3735928559)
==> entered myfunc()
==>     double = 3.141590
==>zlib version is 1.2.3
==> exiting myfunc()
dlsym() using dlopen handle succeeded
dlsym() using RTLD_NEXT succeeded

So, this problem was indeed fixed at some point between 6.1 and
6.4. Thanks for your time.

Markus

-- 
Markus Hoenicka
markus.hoenicka@cats.de
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
Comment 5 Konstantin Belousov freebsd_committer freebsd_triage 2008-11-29 22:48:23 UTC
State Changed
From-To: feedback->closed

Fix confirmed.