Subject: dlopen() from libc is broken
To: None <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 07/17/2004 17:13:27
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:
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
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.
...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 <email@example.com>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----