Re: KDE 2.x and lt_dlopen_flag

[Alexandre Oliva]

On Jun  6, 2001, Michael Matz <address@hidden> wrote:

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

As long as you use libltdl as a convenience library only, it's indeed
minor.  Otherwise, please rename the library, since it's a fork of
libltdl, and should have unrelated version numbers.

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

Do you realize that, if you can't live with LT_GLOBAL, you can't do
dlpreopening on platforms that don't support shared libraries at all?
Instead of papering over the problem, it would be better to avoid
symbol conflicts in the first place.

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

In any case, you shouldn't have removed LT_GLOBAL from the *default*
setting, since this would affect any other user of libltdl.

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

:-)

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

It seems reasonable to introduce libltdl-specific constants that would
be recognized by each dlopening back-end and translated to back-end
specific flags when calling the corresponding dlopen mechanism.

But it would be nice to have ways for the back-end to report whether
it couldn't fulfill the request for a certain feature.

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

The fact that we have this fallback define of LT_GLOBAL to 0 in ltdl.c
implies it is not something you should count on.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me