From nobody@FreeBSD.org  Fri Nov 21 00:07:53 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A36CE106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Nov 2008 00:07:53 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 8CFBF8FC1B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Nov 2008 00:07:53 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mAL07rPC099598
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Nov 2008 00:07:53 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id mAL07qxS099597;
	Fri, 21 Nov 2008 00:07:52 GMT
	(envelope-from nobody)
Message-Id: <200811210007.mAL07qxS099597@www.freebsd.org>
Date: Fri, 21 Nov 2008 00:07:52 GMT
From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Portability issue: accessing symbols in shared objects via dlsym()
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         129031
>Category:       kern
>Synopsis:       Portability issue: accessing symbols in shared objects via dlsym(3)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kib
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 21 00:10:04 UTC 2008
>Closed-Date:    Sat Nov 29 22:48:44 UTC 2008
>Last-Modified:  Sat Nov 29 22:48:44 UTC 2008
>Originator:     Markus Hoenicka
>Release:        6.1-RELEASE
>Organization:
>Environment:
FreeBSD yeti.mininet 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Mon Aug 28 22:24:48 CEST 2006     markus@yeti.mininet:/usr/src/sys/i386/compile/YETI  i386
>Description:
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)


>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-standards 
Responsible-Changed-By: remko 
Responsible-Changed-When: Fri Nov 21 08:45:13 UTC 2008 
Responsible-Changed-Why:  
I think the standards group is a better place for this ticket. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=129031 
State-Changed-From-To: open->feedback 
State-Changed-By: kib 
State-Changed-When: Sat Nov 22 13:25:52 UTC 2008 
State-Changed-Why:  
I believe I fixed the issue long time ago. It should be so in the 
6.3 at least. Please confirm. 


Responsible-Changed-From-To: freebsd-standards->kib 
Responsible-Changed-By: kib 
Responsible-Changed-When: Sat Nov 22 13:25:52 UTC 2008 
Responsible-Changed-Why:  
Grab to watch the response. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=129031 

From: "Markus Hoenicka" <markus.hoenicka@mhoenicka.de>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/129031: Portability issue: accessing symbols in shared objects via dlsym(3)
Date: Sat, 29 Nov 2008 22:50:50 +0100

 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
State-Changed-From-To: feedback->closed 
State-Changed-By: kib 
State-Changed-When: Sat Nov 29 22:48:23 UTC 2008 
State-Changed-Why:  
Fix confirmed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=129031 
>Unformatted:
