GNU bug report logs - #8537
2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment

Previous Next

Full log

View this message in rfc822 format

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: bug#8537: libtool must not depend on existence of system '/usr/lib*/*.la' files
Date: Thu, 28 Apr 2011 20:04:56 +0100

On Thursday 28 April 2011 12:59:05 Mike Frysinger wrote:
> > And I'd still like an answer to the basic question "why is libtool doing so much on Linux
> > when gcc gets it right on its own" ?
> 
> your view of libtool is clouded by your very narrow focus on recent
> versions of gcc/Linux targets.  libtool scales to many many more
> targets, and its complex system is designed to handle severly
> deficient targets.  albeit at the cost of being more complex than
> necessary for some modern/sane targets.
> -mike

But I, as the end user and "distro maintainer" of my own distro, want to produce a compatible
version of libtool for linux for use on it that does not do anything too complicated unless it needs to .

I've always greatly admired autoconf, automake and libtool for their ability to build and install 
software on such a huge variety of platforms, but always hated trying to get them to build
and install software that is truly optimized for only one OS and toolchain .

With a "one size fits all" approach, it is too easy to make all software perform equally poorly on all platforms -
I'm not saying autoconf / automake / libtool does this, but it enforces alot of complicated configuration operations on platforms where
literally typing 'make c.o' where 'c.c' exists will do the job without anything else at all (no Makefile required even) .

I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant replacement for the "configure" step - NO other dependancies required -
that will generate  'Makefile's and ./libtool with very simple commands if it finds itself to be running on a "quick configure platform" , it will skip configure 
and just generate simple autoconf generated files.
I have a make library that can source and execute m4 configure macros,  and could make it construct a "configure" script and "libtool" script in make 
"define ... endef"s that can be dumped to files or sourced . Personally, I prefer programming in GNU make(1) and using macro processors such
as cpp or autotext or the shell to programming in m4 , and there is no reason why this shouldn't be permitted on platforms with a fully functional
GNU development tools and utilities toolchain .

I'll post the results to libtool-devel <at> gnu.org or whatever it should be sent when this is complete and fully tested (for Linux at least).

All the best,
Jason

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.