Status of libtool 2.2.X?

Adam Jackson ajax at redhat.com
Fri Oct 10 19:24:26 UTC 2008


On Fri, 2008-10-10 at 12:07 -0700, Toshio Kuratomi wrote:
> Adam Jackson wrote:
> > On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> >> Hand coding Makefiles to compile shared libraries on all platforms is .
> >>  Before libtools many upstreams simply wouldn't package shared libraries
> >> because of all the problems with getting it right for SunOS, Solaris,
> >> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
> >> etc.  If the state of the art has advanced and there's a tool that can
> >> replace libtool so a developer can say "I want a shared library" and the
> >> tool builds it on all platforms then we could look into getting
> >> upstreams to switch but simply getting rid of libtool in favour of
> >> handcoding Makefiles to build shared libraries is a step in the wrong
> >> direction.
> > 
> > The state of the art is "gcc -shared".
> > 
> So gcc is the compiler everywhere these days?  Note this is a genuine
> question -- I haven't used anything besides Linux in so long I don't
> know whether Sun or anyone else is shipping their own C compiler anymore.

Sun cc is pretty similar, but solaris has gcc installed well over half
the time anyway.  *BSD and OSX are all gcc, Windows is effectively gcc
for open source projects, and there are no other operating systems.

Most of the complexity in libtool (and autotools in general) is to
support systems that simply are not worth supporting and that
practically speaking don't exist anymore.  I'm being slightly flip in
saying 'gcc -shared' but really not by much.  Honestly for any fringe
platform the correct thing to do is port gcc/binutils/gmake first.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/6ad33710/attachment.sig>


More information about the fedora-devel-list mailing list