Re: KDE 2.x and lt_dlopen_flag

[Michael Matz]

Ho,

On 8 Jun 2001, Alexandre Oliva wrote:

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

convenience only.  (although I heard, that *BSD tried to unify all
libltdl's, high Nick ;) )

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

Yes.
KDE will not run without _major_ work on such platforms.  Or better not
all parts of KDE will run.  For one, we e.g. don't link against all
possible plugins (which normally would be loaded dynamically), which also
prevents dlpreopening from work.  This anyway is the case for most highly
pluginned systems, as there are plugins which don't exist at application
link time, but still need loading for the system to work in one way or
another.  I.e. without sharedness we are doomed.
(This only applies to the base system, i.e. the DE in KDE, normal
applications could usually be linked against our libraries and be done
with it, only that they can't use their own widget style in this case,
which means, they wouldn't integrate as smooth into the system as
otherwise).

> Instead of papering over the problem, it would be better to avoid
> symbol conflicts in the first place.

IIRC we once had a conflict in C++ symbols between our kwin plugins and
libfam, the latter being not from us, so we had no control over it.  This
was an internal interface (both of kwin and of libfam, in kwin it's a
private class), so libfam shouldn't have exported it.  The kwin plugins
would have been fine, because the symbol there was used nowhere in KDE,
just that that crappy libfam symbol got into the way, because of
libkdecore being linked to it (on some platforms).  As in my eyes it's
libfam's fault we hadn't changed our symbols, but did what we did.  Even
if we had changed it, we couldn't have been sure, that there are no other
C++ symbols in the system not controled by KDE.  So anyway it would have
been a fragile solution.

Also libfam isn't really faulty, as currently (and even more at the time
of the writing of that lib), it was not exceedingly easy to prevent any
C++ symbols from being exported.

That is not to say, we wouldn't _like_ to prevent symbol conflicts,
just, that with C++ it's not as easy as said.

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

As said, convenience only, so we are the only user of _that_ libltdl.

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

Ok.

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

Then we at least need a better error API at all.  The current lt_dlerror,
which just returns (char *) is less than optimal for this.  At least an
error-code based thing would be needed.

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

Hmm.  But there must be ways on each reasonable platform, that a DSO does
_not_ export all it's symbols into the table which also is searched by
other DSOs or by the app.  Otherwise a real generic plugin mechanism can't
be implemented.  I.e. in the absence of such mechanisms all plugins would
themself be responsible to not produce conflicts even without knowing of
all other plugins, which can't be done.  The latter problem can be reduced
by limiting the exported symbols to lower probabilities of conflict, but
for C++ that's difficult.


Ciao,
Michael.