Re: linking modules into programs problem

[Nick Hudson]

Michael Matz wrote:
> 
> 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?

And here lies the crux of my problem. In NetBSD pkgsrc we're (well I'm)
trying to maintain one libtool that works for all packages. Rather than
maintaining N libtools where N>250.

I know this is not really your problem, but the pkgsrc libtool for a.out
doesn't cope with KDE 2 due to some modules being linked into programs
(and that NetBSD pkgsrc libtool for a.out has need_lib_prefix=no - the
reasons for this I think I've already explained)

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

I should have made it clear from the outset that if you're happy to go
in this direction I am more than happy to provide diffs for the required
changes. Intially I was trying to see if there was some magic (other
than need_lib_prefix) in libtool to solve the problem.
>
> 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?

Correct.

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

That's even advised against in the libtool documentation IIRC.

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

Don't know about any platforms other than Darwin...

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

I don't really understand this... 

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

But you can't force people to read documentation. They expect certain
behaviour - see my "principle of least surprises" comment.

Finally, I would just like to thank you both for paying attention and
please keep up the good work on libtool and KDE.

Nick
-- 
aka address@hidden, address@hidden