Re: libgomp and python: dlopen fails

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Sebastian Steiger writes:
 > The interesting part of the output when LD_DEBUG=all is this:
 > 
 >      21475:     file=libgomp.so.1 [0];  generating link map
 >       21475:     symbol=dlerror;  lookup in file=python
 >       21475:     symbol=dlerror;  lookup in 
 > file=/usr/lib64/libpython2.3.so.1.0
 >       21475:     symbol=dlerror;  lookup in file=/lib64/tls/libpthread.so.0
 >       21475:     symbol=dlerror;  lookup in file=/lib64/libdl.so.2
 >       21475:     binding file /usr/lib64/libpython2.3.so.1.0 to 
 > /lib64/libdl.so.2: normal symbol `dlerror' [GLIBC_2.2.5]
 >       21475:     symbol=__dcgettext;  lookup in file=python
 >       21475:     symbol=__dcgettext;  lookup in 
 > file=/usr/lib64/libpython2.3.so.1.0
 >       21475:     symbol=__dcgettext;  lookup in 
 > file=/lib64/tls/libpthread.so.0
 >       21475:     symbol=__dcgettext;  lookup in file=/lib64/libdl.so.2
 >       21475:     symbol=__dcgettext;  lookup in file=/lib64/libutil.so.1
 >       21475:     symbol=__dcgettext;  lookup in file=/lib64/tls/libm.so.6
 >       21475:     symbol=__dcgettext;  lookup in file=/lib64/tls/libc.so.6
 >       21475:     binding file /lib64/libdl.so.2 to /lib64/tls/libc.so.6: 
 > normal symbol `__dcgettext' [GLIBC_2.2.5]
 >       21475:     symbol=__asprintf;  lookup in file=python
 >       21475:     symbol=__asprintf;  lookup in 
 > file=/usr/lib64/libpython2.3.so.1.0
 >       21475:     symbol=__asprintf;  lookup in 
 > file=/lib64/tls/libpthread.so.0
 >       21475:     symbol=__asprintf;  lookup in file=/lib64/libdl.so.2
 > 
 > < The rest is just python stuff for error handling and screen output.>
 > 
 > 
 > 
 > This encouraged me to take a sample C++ file for testing dlopen() which 
 > I found on the internet:
 > 
 > 
 > #include <iostream>
 > #include <dlfcn.h>
 > using namespace std;
 > 
 > int main()
 > {	
 >      void* handle = dlopen("(...)/libgomp.so.1", RTLD_LAZY);
 > 
 >      if (!handle) {
 >          cerr << "Cannot open library: " << dlerror() << '\n';
 >          return 1;
 >      }
 >      cout << "Loading was successful. Closing library...\n";
 >      dlclose(handle);
 > }
 > 
 > 
 > 
 > I compiled this file with g++4 -o dlopen_test.bin dlopen_test.cpp -ldl 
 > (I called the file dlopen_test.cpp) and got the following output:
 > 
 > "Cannot open library: (...)/libgomp.so.1: shared object cannot be 
 > dlopen()ed"
 > 
 > 
 > Obviously the output of the python shell was just dlerror(), but it is 
 > not very instructive.
 > 
 > I also tried RTLD_NOW instead of RTLD_LAZY, but the error was the same.

This message comes from the dynamic linker:

  /* Make sure we are not dlopen'ing an object
     that has the DF_1_NOOPEN flag set.  */
  if (__builtin_expect (l->l_flags_1 & DF_1_NOOPEN, 0)
      && (mode & __RTLD_DLOPEN))
    {
      /* We are not supposed to load this object.  Free all resources.  */
      __munmap ((void *) l->l_map_start, l->l_map_end - l->l_map_start);
...
      errstring = N_("shared object cannot be dlopen()ed");
      goto call_lose;
    }

Because when you (or someone else) built libgomp.so.1, the object
was marked with the NOOPEN flag. From "info ld":

  -z nodlopen
          Marks the object not available to `dlopen'.