This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Patch to update libtool in GCC and Src trees
On Tue, 15 May 2007 16:55:55 +0200, "Paolo Bonzini" said:
> > you'll need to implement some
> > mechanism of completely *disabling* --enable-shared for all but
> > i*86-linux, while still defaulting to --enable-shared --enable-static on
> > linux.
>
> case "$target" in
> i*86-*-linux*) ;;
> *) enable_shared=no ;;
> esac
Um. yeah. That was pretty obvious, wasn't it. <blush>
> > (1) make the Makefile.am changes I detailed (all 75 or only 15)
> > (2) modify the 15 configure.in's with
> > (a) _LT_DECL_SED outside the existing 'if' -- /if/ that works
>
> If it works, I would very much prefer that, because running useless
> libtool tests is not the best thing to do (especially given the time it
> takes).
It turns out that within newlib the time involved wasn't that big -- it
appeared that many of the tests were cached between newlib's
(sub)projects. But I take your point.
I was discussing this with Ralf W. (one of the libtool maintainers)
off-list, and he said:
Ralf W. wrote:
"I think it suffices to get $SED and $Xsed right, and be aware of some
macros that may be needed by other macros. Paolo's approach to use
_LT_DECL_SED looks good to me, but I haven't tested it"
He also included the following warning:
"Be sure to have called the following macros beforehand, if you or
another macro that comes after the libtool macros needs them:
AC_PROG_CC, AC_CANONICAL_BUILD, AC_CANONICAL_HOST, AC_PROG_LN_S,
AC_PROG_EGREP, AC_PROG_FGREP."
With Ralf's permission, I will forward his entire message to the list,
separately.
> > (b) or unconditionally call LT_INIT like I did, but also add
> > AC_NO_EXECUTABLES
> > (3) re-aclocal, re-automake, re-autoconf yadda yadda
>
> There's another possibility, actually, which is to import *the libtool
> tree* in the gcc/src tree from upstream and build it as a target module.
> Then, instead of having each library build its own libtool, use the
> common one.
>
> I wonder if this is not a much much better idea.
I don't think so. The built libtool script includes information about
the compiler(s) it was configured with, including the name/(location?)
of the language's runtime libraries and startup objects. If the libtool
"module" is built after the frontends, but before the libraries, the
information it collects during its own build (which it then records for
later use during the build of the target libs) will be wrong. Or at
least, incomplete.
So, ideally, you'd rebuild libtool after each target lib anyway, to
update the recorded info. But that's no different than just building a
new libtool script inside each target lib's build directory, as is done
now. I *think* the only way that a libtool "module" would work (in the
expected "straightforward" manner) is if you were building a target
library standalone, using an external compiler -- not during a compiler
bootstrap.
Now, maybe, if there are NO inter-library dependencies other than on
libgcc (which never uses libtool), then this is all moot, and the
preceding paragraph doesn't apply. However, even if that is the case,
IMO libtool is not very well tested as a standalone tool. (The use case
proposed by Paolo is kinda halfway between "build a libtool for each
(sub)project" and "standalone" -- we'd build one and only one libtool
for this /group/ of language-inhomogeneous but simultaneously-built
(sub)projects, but each (sub)project would then treat that libtool
script as a standalone tool).
Libtool's normal use case is to be built as part of *each* project's (or
subproject's) configure process. In fact, it was even suggested at one
point that support for "standalone" libtool be dropped. This suggestion
was rejected, but it demonstrates that standalone use is sadly
neglected. I don't think gcc/ and src/ want to rely on a neglected use
case of a supporting tool -- or risk that the sort of halfway
no-man's-land between "build for each" and "standalone" won't lead to
yet more issues, unique to the halfway zone. That'd be the worst of
both worlds.
Unless you want to use gcc/+src/'s status as the 800-lb gorilla to goad
the libtool folks into supporting "standalone" libtool (and halfway
zone?) more seriously?
--
Chuck