Re: linking modules into programs problem

[Michael Matz]

Hi,

On Mon, 19 Mar 2001, Christoph Pfisterer wrote:
>
> As you mention, some platforms allow this, others don't. The purpose
> of libtool in my eyes is to provide a common denominator for as much
> platforms as possible.

Agreed.  But nobody said it must be the _lowest_ common denominator ;)
This is a very convenient feature (linking modules).  Hmm...

> >But on many systems this is allowed, so an error would seem strange.
>
> Well, there _are_ systems where linking in modules as if they were
> shared libraries is not only not allowed, but impossible. One example
> is Darwin (a.k.a. the open-sourced, BSD- and Mach-based kernel of Mac
> OS X). It uses the Mach-O file format, which differentiates between
> shared libraries (file type MH_DYLIB) and modules (file type
> MH_BUNDLE). Only the libraries can be linked against and only the
> modules can be dlopen()'ed.

Bad.  A real cool way around that would be, if libtool itself built (when
-module is given) both, the library and the module (which should be
possible, as the -module command line should include all necessary
arguments for libtool to build also the lib) on those platforms, and so
hides that fact.  When linking against such a .la file, it would take the
library, when lt_dlopen'ing the module.  In this way, the complexity is
hidden by libtool, which is it's whole purpose.  Now, if libtool itself
wouldn't be so cumbersome to extend, this might even be implementable ;)

> >libtool would prevent modules from being linked into executables, we would
> >link many of our (KDE-) modules two time (as modules and as lib), thereby
> >doubling the binary size, for no good reason (and all the Makefile.am
> >would need fixing, doh ;) )
>
> Hmmm, and I had hoped porting KDE to Darwin would be easy...

Well, in my experience the libtool part is the ugliest thing.  Unless
there is no good C++ support by the compiler on that platform, supporting
at least correct static constuctors in dlopen'ed objects.  If there is
not, (that **** HP-UX comes to mind), this is tougher.  (Basically, if you
can get a C++ test-case involving a simple main program, and three
shared libs, forming a diamond pattern, and having some static objects
inside, to work, chances are good.  Bonus points, if even lt_dlclose()
works and calls the destructors ;) )  All the other stuff (terminals,
networking) is fairly straight forward.


Ciao,
Michael.