Re: static vs. dynamic linking

[Enrico Weigelt]

* Ralf Wildenhues <address@hidden> wrote:

Hi,

> > how does libtool decide whether to link against an .la library 
> > dynamically vs. statically ?
> 
> For a program or a library?  Uninstalled or installed library
> (see recent bug report of Howard Chu)? 

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.

> 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 ...
Isn't there any document which describes what is done in these
situations (not the actual command line, but at least the actions) ?!

<snip>

> > I'm currently working on my own implementation, since libtool 
> > doesn't suit my needs (ie. sysroot'ed building), but I didn't
> > find any clear specification for libtool's behaviour.
> 
> 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.

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

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.

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

You may have a look at it:

    cvs://anonymous:address@hidden/unitool/
    
The idea bind is: you have a very minimalistic command set with 
an very simple syntax. No platform dependent stuff is visible here, 
neither what compiler you use. Evrythings hidden behind unitool.
No more annying and unreliable autodetection on every package. 
For each toolchain an unitool instance is configured *once*, 
maybe with the help of some autoconfiguration, and then it's just
passed to the individual package.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     address@hidden
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------