Re: lib/49791: dlopen(0, and dlopened libraries

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

The following reply was made to PR lib/49791; it has been noted by GNATS.

From: Patrick Welche <prlw1%cam.ac.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/49791: dlopen(0, and dlopened libraries
Date: Sat, 4 Apr 2015 19:32:34 +0100

 On Fri, Mar 27, 2015 at 05:50:01PM +0000, Joerg Sonnenberger wrote:
 >  On Thu, Mar 26, 2015 at 11:45:00PM +0000, prlw1%cam.ac.uk@localhost wrote:
 >  > that our dlopen() does (cf dlfcn(3))
 >  > 
 >  >      If the first argument is NULL, dlopen() returns a handle on the global
 >  >      symbol object.  This object provides access to all symbols from an
 >  >      ordered set of objects consisting of the original program image and any
 >  >      dependencies loaded during startup.
 >  
 >  This is the same behavior documented on glibc
 
 According to Ubuntu 14.04.2 dlopen(3):
 
    If filename is a NULL pointer, then the returned handle is for the main
    program.  When given to dlsym(), this handle causes a search for a sym
    bol in the main program, followed by all  shared  libraries  loaded  at
    program  startup, and then all shared libraries loaded by dlopen() with
    the flag RTLD_GLOBAL.
 
 So this has the 3rd clause missing from our description, yet present
 in the posix description:
 
 >  > whereas accoding to posix in
 >  > 
 >  >   http://pubs.opengroup.org/onlinepubs/007904975/functions/dlopen.html
 >  > 
 >  > If the value of file is 0, dlopen() shall provide a handle on a global
 >  > symbol object. This object shall provide access to the symbols from an
 >  > ordered set of objects consisting of the original program image file,
 >  > together with any objects loaded at program start-up as specified by
 >  > that process image file (for example, shared libraries), and the set
 >  > of objects loaded using a dlopen() operation together with the
 >  > RTLD_GLOBAL flag. As the latter set of objects can change during
 >  > execution, the set identified by handle can also change dynamically.
 >  
 >  This, frankly, doesn't make sense.
 >  
 >  > glib assumes the posix variant, and we have a patch in pkgsrc to detect ours as broken.
 >  
 >  How can it? It doesn't seem like glibc provides the same:
 >  
 >    If filename is NULL, then the returned handle is for the main program.
 >  
 >  > #include <err.h>
 >  > #include <dlfcn.h>
 >  > #include <stdio.h>
 >  > 
 >  > int main()
 >  > {
 >  >     void *handle;
 >  > 
 >  >     handle = dlopen ("libm.so", RTLD_GLOBAL | RTLD_LAZY);
 >  >     if (handle == NULL)
 >  >         errx(1, "dlopen of libm failed (%s)", dlerror());
 >  > 
 >  >     handle = dlopen (NULL, 0);
 >  >     if (handle == NULL)
 >  >         errx(1, "dlopen of global symbol object failed (%s)", dlerror());
 >  > 
 >  >     handle = dlsym (handle, "sin");
 >  >     if (handle == NULL)
 >  >         errx(1, "sin() not found in libm (%s)", dlerror());
 >  
 >  I think the "correct" behavior here is:
 >  
 >  dlsym(RTLD_DEFAULT, "sin");
 
 Interestingly, glib didn't worry about autoconfigury when android support
 came along, and committed:
 
 #ifdef __BIONIC__
   handle = RTLD_DEFAULT;
 #else
   handle = dlopen (NULL, RTLD_GLOBAL | RTLD_LAZY);
 #endif
 
 So maybe this is the way forward. How do you decide on "correct"?
 Could you give me some pointers to why RTLD_GLOBAL is a bug, and the
 problems with subsequent dlclose()?