Ulrich Drepper writes:
> Mikael Pettersson <mikpe@xxxxxxxxx> writes:
>
> > Richard is correct -- RTLD_NEXT seems to have been mutilated
> > beyond recognition in glibc-2.2.
> >
> > Observe:
> >
> > > Script started on Mon Feb 5 13:19:19 2001
> > > stout_1_cat bug.c
> > > #define _GNU_SOURCE /* wtf?! RTLD_NEXT is undefined otherwise */
> > > #include <dlfcn.h>
> > > int main(void) { dlsym(RTLD_NEXT, "sigaction"); return 0; }
> >
> > Nothing fancy here.
>
> Dammit, no. You people simply cannot program. This code is broken.
> If it worked before this is only by accident.
No need to be rude! I can code just fine, thank you. The problem lies
in the (lack of) documentation. The man page for dlsym() says nothing,
and /usr/include/dlfcn.h isn't sufficiently explicit. Adding a single
sentence:
Use of RTLD_NEXT from outside a shared library context will result in
undefined behaviour
would help. Reading the Solaris 2.6 man page, I don't see a similar
warning. So, according to the sources available to me, RTLD_NEXT is
fine.
Furthermore, under libc 5 there *is no* RTLD_DEFAULT, so it's hardly
surprising that RTLD_NEXT is what people have been using. Does glibc
still claim to be binary compatible with libc 5? If so, what will
happen to a libc 5 compiled programme which can only use RTLD_NEXT? Do
you have special casing to prevent breakage in that case?
Finally, why don't you have error checking in your library? If the
usage is in fact wrong, isn't is cleaner to return NULL from dlsym(),
rather than having it segfault?
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|