Re: RTLD_LAZY considered harmful (Re: pltlc and pltlcu

I hate to sound like a broken record, but I want to re-open that
discussion about RTLD_LAZY binding that trailed off a week or two
ago.  I have just noticed that the 7.0 and 7.1 versions of
src/backend/port/dynloader/linux.h have

#define pg_dlopen(f)    dlopen(f, 2)

which in 7.2 has been changed to

#define pg_dlopen(f)    dlopen((f), RTLD_LAZY | RTLD_GLOBAL)

But a quick look in /usr/include/bits/dlfcn.h shows that (at least
on RH Linux 7.2), the old coding was equivalent to RTLD_NOW.

I therefore assert that the current coding is effectively untested
on Linux, which is probably our most popular platform, and therefore
it should *NOT* be accorded the respect normally due to the status
quo.  Arguably, 7.2 has introduced breakage here.

A grep through the 7.1 versions of src/backend/port/dynloader/*.h
shows the following rather motley assortment of dlopen flag choices:

aix.h:61:#define  pg_dlopen(f)  dlopen(f, RTLD_LAZY)
bsdi.h:23:#define         pg_dlopen(f)    dlopen(f, RTLD_LAZY)
dgux.h:26:#define pg_dlopen(f)  dlopen(f,1)
freebsd.h:36:#define           pg_dlopen(f)    BSD44_derived_dlopen(f, 1)
irix5.h:29:#define pg_dlopen(f) dlopen(f,1)
linux.h:34:#define pg_dlopen(f) dlopen(f, 2)
netbsd.h:36:#define        pg_dlopen(f)    BSD44_derived_dlopen(f, 1)
openbsd.h:36:#define           pg_dlopen(f)    BSD44_derived_dlopen(f, 1)
osf.h:31:#define  pg_dlopen(f)  dlopen(f, RTLD_LAZY)
sco.h:29:#define pg_dlopen(f)   dlopen(f,1)
solaris.h:9:#define pg_dlopen(f)    dlopen(f,1)
sunos4.h:29:#define pg_dlopen(f)    dlopen(f, 1)
svr4.h:29:#define pg_dlopen(f)  dlopen(f,RTLD_LAZY)
univel.h:29:#define pg_dlopen(f)    dlopen(f,RTLD_LAZY)
unixware.h:29:#define pg_dlopen(f)  dlopen(f,RTLD_LAZY)
win.h:29:#define pg_dlopen(f)       dlopen(f,1)

In 7.2 these have all been changed to "RTLD_LAZY | RTLD_GLOBAL", but
I am no longer willing to presume that that's equivalent to the
original coding.  Could people who have these platforms look to see
what the numeric values mentioned above actually equate to on their
platforms?
        regards, tom lane