Re: libltdl should not always use LT_GLOBAL

[Alexandre Oliva]

On Mar 13, 2004, Scott James Remnant <address@hidden> wrote:

> This flag causes the external symbols defined in the library to be made
> available for symbol resolution of subsequently loaded libraries.  This
> isn't the default behaviour of dlopen().

But it is the default behavior of static linking.  Remember that
libtool is not about creating shared libraries, it's about giving a
unified abstraction of libraries.  This implies that the least common
denominator has to be taken in general.  Since you can't depend on the
existence of shared libraries, or a user may choose to disable them,
libtool requires the judicious use of the -dlopen flag to indicate
that a library may be dlopened at run time, such that, if it happens
to be a static library, libtool can link it into the application and
set things up for the dlopen emulation over static linking to work.
Heck, even if you do have shared libraries, the semantics of symbol
binding vary.

Should we dlopen libraries without flags that made them behave as
closely as possible to static linking, people would likely not realize
they were breaking the abstraction layer that libtool offers.

> libdriver defines the external symbol InitFoo().
> libbar also defines an external symbol called InitFoo() with different
> semantics.

Since this cannot be implemented correctly when using static linking,
this scenario is not supported by libtool.  We *might* introduce a
work around and enable people to pass flags to dlopen, but this would
probably just make room for people to keep on abusing the libtool
interface.  Granted, most people who use libtool are not interested in
the static library case, but I don't think we should make it too easy
for people to break the abstraction layers.  If they definitely want
to assume shared libraries and ELF library semantics, let them just
use dlopen!

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}