Re: KDE 2.x and lt_dlopen_flag

[Nick Hudson]

Michael Matz wrote:
> 
> Hi,
> 
> On 5 Jun 2001, Alexandre Oliva wrote:
> > On Jun  4, 2001, Nick Hudson <address@hidden> wrote:
[...]
> > > --- 575,588 ----
> > >   #  define DLERROR(arg)    LT_DLSTRERROR (arg)
> > >   #endif
> >
> > > + int lt_dlopen_flag = LT_LAZY_OR_NOW;
> > > +
> ...
> > > !   lt_module   module   = dlopen (filename, lt_dlopen_flag);
> 
> Ahh that one.  I now for long wanted to get rid of that global and instead
> add an argument to lt_dlopen().  Everytime I wanted to do this we
> magically were in a feature freeze, and after that I forgot ;-)

Are you in feature freeze now?

> > Do they realize that this change removed LT_GLOBAL from the default
> > lt_dlopen_flag setting?

It looks as though they do :-)

> That's the whole point of the patch.  Initially there was no such global
> at all, and we simply removed the LT_GLOBAL from the flags.  This was
> needed to prevent some symbol conflicts on some dynamically loaded
> modules.  As lt_dlsym() still worked, the removing of LT_GLOBAL was all,
> what was necessary, as we only need the address of some "init" function.
> 
> Then the need arose for dynamically loading a library (and by that the
> need for exporting all symbols in that lib, i.e. LT_GLOBAL), so this flag
> was added, as I was away ;-)
> 
> > I can't say I like this approach.  Tweaking lt_dlopen_flag is not
> > guaranteed to have any effect on the outcome of a lt_dlopen, since
> > there's no guarantee that dlopen() is going to be used.
> 
> Yep, that's why I wanted to add a flag argument to lt_dlopen() (for
> implementing at least the possibility to load modules without
> automatically exporting symbols).  I'm aware, that lt_dlopen_flag only
> changes dlopen() platforms (although the only other platform which libltdl
> supports, and on which KDE runs, of which I'm aware off, is HP-UX with
> it's shl_load, and there we have more serious problems than conflicting
> symbols (static ctors/dtors in DSOs, to name them)).

So can you create the patch against libtool and submit it? If you are in
feature freeze you can obviously merge in the change later.

> > To me, tweaking the dlopen() flags is entering non-portable zone and,
> > since you're doing that, why not use dlopen() directly?
> 
> As I said, we only use this to switch from exporting to not exporting
> symbols, and this functionality should be portable.  I at least hope so?

What about cygwin/darwin/aix?

Nick