Re: KDE 2.x and lt_dlopen_flag

[Michael Matz]

Hi,

On 5 Jun 2001, Alexandre Oliva wrote:
> On Jun  4, 2001, Nick Hudson <address@hidden> wrote:
> > - libltdl_la_LDFLAGS = -no-undefined -version-info 3:0:0
> > + libltdl_la_LDFLAGS = -no-undefined -version-info 3:1:0
>
> This is wrong.  Since they have added an interface, CURRENT and AGE
> should have been incremented, and REVISION left as zero.

Well, that incrementing actually was part of the KDE 2.0->2.1 (or 2.2)
move, not by the addition of that variable.  Anyway that's a minor issue.

> > --- 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 ;-)

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

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)).

> 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?


Ciao,
Michael.