Re: linking modules into programs problem

[Michael Matz]

Hi,

On Thu, 29 Mar 2001, Nick Hudson wrote:
> > > My main problem with changing need_lib_prefix is that its counter
> > > intuitive to the user and actually breaks some pkgs in NetBSD pkgsrc
> > > that have made the assumption that building a with -o name.la -module
> > > results in an object of the form name.so.

But KDE uses it's own version of libtool, so if you only change it in this
copy everything should work.  We _don't_ assume strange things from
libtool and use libltdl (we assume currently that it's somehow possible to
use modules for linking, though).  Your initial question was how to cope
with KDE.  From the above disussion I read, that you want to use a global
libtool in the NetBSD tree and need to take that into account when
changing libtool?  Hmm, wait, I now looked and see that KDE's libtool even
_does_ set $need_lib_prefix on NetBSD (OK, it doesn't set it to "no" which
means the same thing for libtool), so why do you have this problem in the
first place?

Anyway, I'm in the process of looking into all of KDE's modules (or
Makefile.am's) for those which get linked into other things.  I might be
faster if I get a list of those.  Then I try to make them libs and
modules.  I'm not happy about that.

Before that some question, that I don't have to do this some time later again:
Currently in KDE we have:
(1) real libs; prefixed with lib and never lt_dlopen's
(2) real modules; not prefixed with lib, never linked to anything (only
    runtime-linked)
(3) modules _prefixed with lib_ (even the .la file); runtime linked and
    normally linked
(4) modules without libprefix (the .la file at least); runtime- and
    normally linked

I guess (1)-(3) are working on NetBSD, and only (4) makes problems?
I guess further that on any platform on which (1)-(3) is working also (4)
can be made working with the $need_lib_prefix setting in libtool. (I once
changed all of KDE to never have libxxx.la and xxx.la in the same
directory, because that breaks on $need_lib_prefix platforms).
This means that the change I'm going to make is only needed on platforms,
on which (1)-(3) are _not- working.  If either (1) or (2) is not working
on a platform, KDE will not work on that, so we only talk about platforms
on which (3) is not working.  Which are those? (this thread releaved
Darwin is such a bloody thing, others?).

Furthermore: on those platforms, would something like this work:
create libbla.la from some .lo's
create module.la from dummy.lo and libbla.la?  Or does that not export all
symbols from libbla.la?  Then I might need -export-dynamic (we want to
avoid that flag); does that work on all platforms? (I only see definitions
for this flag for HP-UX, Solaris and GNU ld).  If the above doesn't work,
would at least work something like
create module.la from factory.lo and libbla.la?  Here factory.lo is
supposed to contain all routines which need to be dynamically exported (we
often have the factory pattern in KDE, which means we mostly only need to
export one routine, which even doesn't need to be called, when used by a
part which links directly to the library).

> >
> > OTOH, no one should expect creating a name.la -module to result in
> > name.so.  There's no such guarantee.  You can extract the lib name
> > from the .la script, but, if you decide to guess it by yourself, you
> > risk guessing wrong, and you can't blame libtool for that.
>
> I understand that and I'm not blaming libtool. Unfortunately it seems
> that hardly anyone reads the documentation and so they expect certain
> behaviour. The naming of modules is an example. I am suggesting that
> libtool adopt the principle of least surprises and make name.la -module
> produce name.so wherever possible.

Define possible ;)  From my PoV it's not possible on NetBSD a.out (because
the linker doesn't find such modules, although they can be linked in, if
the file is renamed), from your PoV it's possible.  Those views are
conflicting, bad.

> Is this unreasonable?

No.  But it's also not unreasonable to ask people to read documentation
and to use libltdl, if they use libtool.


Ciao,
Michael.