Re: static vs. dynamic linking

[Ralf Wildenhues]

Hi Enrico,

* Enrico Weigelt wrote on Tue, Sep 27, 2005 at 03:27:21PM CEST:
> * Ralf Wildenhues <address@hidden> wrote:
>
> > > how does libtool decide whether to link against an .la library 
> > > dynamically vs. statically ?
> > 
> > For a program or a library?  Uninstalled or installed library

> Each of these cases ...
> 
> I've now figured out, that libs without rpath are linked statically.
> It seems the chain starts at the Makefile.am file where some libs
> are defined not to be installed. These libs don't get an --rpath
> option, so the resulting .la file has no (or empty) libdir.
> In the end these libs are linked statically.
> 
> Very mustic.

Not at all.  It is all documented quite extensively in the Automake and
the Libtool documentation.  This specific answer is given in
  info libtool "Linking executables"
and 
  info libtool "Linking libraries",

and, by the way, has little to do with your question.  You asked about
when linking some output _against_ a library statically or dynamically,
not when _creating_ a static or dynamic library.

> > On a system with both static and shared libraries, or just one of 
> > them? When the user has configured --{enable,disable}-{static,shared} 
> > or added -static or -all-static?
> 
> GNU/Linux, i686, GCC.
> 
> > For a normal dependency library or a
> > module dependency, or maybe a convenience archive?
> 
> Your dozens of questions show an lack of clear definitions ...

Not at all either.  Your guessing shows you did not read documentation.

> Isn't there any document which describes what is done in these
> situations (not the actual command line, but at least the actions) ?!

Yes, there is.  See above.  No, the manual is not short.

> > We have better support for sysroot and/or DESTDIR on our TODO list.
> 
> Yes, its been there for quite a while. Todo-Lists dont help me, 
> I have to get things working right now.

Oh, sure.  You can probably find someone that implements it for you
in a given time frame, if you pay for it.

> > Why don't you help us improve and fix libtool?  That is bound to be
> > a lot less work.
> 
> I've tried. But I had to find out that it's not repairable in a
> considerable time.

Well, for one you did not even bother to answer any questions I asked
back when you reported this first.  Neither asked whatever else you
needed to know, or showed what you've tried (except the first patch).

> BTW: I dislike the concept of libtool at all (not the fact that 
> we have an tool for building libs, but the way it works, ie. the
> unclean command line options, the quite unspecified behaviour, etc).
> This applies to the whole autotools stuff.

Sorry, I love to discuss technical matters even if people disagree with
me or do not use the tools I use.  I don't mind at all.
(We even go to lengths to make libltdl usable in projects without
Autoconf/Automake)

But I _do_ dislike unqualified bashing.  Get your facts straight, read
documentation of whatever tools you use, and _then_ complain about
whatever doesn't work or what should be done differently.  I told you
that last time as well.

> That's why I started my own toolchain abstraction, with an libtool 
> compatible frontend.

How can it be libtool compatible if you don't know how libtool works?

Cheers,
Ralf