Re: Problem with LT 2.1a

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Wed, Sep 06, 2006 at 05:37:20PM CEST:
> On Thu, 7 Sep 2006, Peter O'Gorman wrote:
> >On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
> >>
> >>We could add another interface
> >>  lt_dlopen_flags (const char *filename, int flags);
> >>
> >I'd prefer to be more specific - lt_dlopen_global(const char * filename)

Well, the disadvantage being that whenever the next flag comes up that
we would like to be able to choose, we cannot just add another #define
to ltdl.h, but have to invent yet another function.  (Not now, but in
some years another flag may just be portable enough; or simply necessary
for some reason.)

And, playing devil's advocate for a minute: why should local symbols be
the default?  Global namespace is more like static linkage (dlpreopening
if you like), so why should that not rather be the default, just as it
was with Libtool-1.5.x?

(I don't really think this is such a good idea, but IIRC Alexandre Oliva
mentioned a similar reasoning once.)

> >The docs would specify that it would attempt to open it in the global 
> >namespace, but may, in fact, open it locally if there is no API to open 
> >globally.
> 
> This is a good idea but I think that it should refuse to load the 
> library/module and return an error instead since if the application 
> requires use of this API, it is likely broken.  It is better to know 
> about breakage sooner than later.
> 
> A more radical approach would be to not expose the lt_dlopen_global 
> interface at all if it can't be supported (using #error to report an 
> error message).  That would cause a compile time failure so that the 
> person building the software can investigate possible alternative 
> build methods.

That could be had, too, with #define's we would not expose.

What I'm rather not sure of is whether we can find out for certain at
configure time whether we can (or the user needs to) open a certain
library with a local name space.  At least it's not clear to me that
on AIX this does not depend on whether the module being opened was
runtime-linked or not.

In any case, it seems prudent to check some of the backends for glitches
like this before actually adding an interface.

Cheers,
Ralf