Subject: dlopen() from libc is broken
To: None <>
From: Jason Thorpe <>
List: tech-toolchain
Date: 07/17/2004 17:13:27
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


Currently, dlopen() et al called from libc is broken.  I believe it was 
broken by the following:

revision 1.33
date: 2003/08/12 09:18:50;  author: skrll;  state: Exp;  lines: +39 -2

Resolve dlsym(3) and friends directly so that dlsym(RTLD_NEXT,...) 

Previously dlsym resolved to the version in crt0.o or libc which would
mean that the caller's shared object couldn't be determined correctly
using __builtin_return_address(0).

Mainly from FreeBSD, but adapted by me. Benefits of this solutions are:

         - backward comptibility maintained
         - existing broken binaries are fixed with a new ld.elf_so
         - __mainprog_obj can be removed from crt0.o
         - we do the same thing as FreeBSD

Fixes PR 22067.

OKed by Jason and Christos.

What happens is that some file in libc that wants to use dlopen() gets 
it renamed to __dlopen() via namespace.h:

00000000         *UND*  00000000 __dlopen
00000000         *UND*  00000000 __dlsym
00000000         *UND*  00000000 __dlerror

ld.elf_so does not do any patching up of these symbols, for two reasons:

1. They're not weak.
2. They're not in the "export list" for ld.elf_so. we end up resolving to the version in libc/dlfcn/dlfcn_elf.c, 
which is an error stub.

I'm surprised none of the i18n people have noticed this yet.  I tripped 
over this while working on dynamic module support for nsswitch, which 
would be working if not for this.

What should we do about it?

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)