[PATCH 1/6] Avoid that autom4te complains about unexpanded macros

This patch series has the purpose of removing the fallback echo code from Libtool, replacing it with usage of printf. More detailed information on the tradeoffs and the rationale are in the description of patch 6/6. In the meanwhile, the series cleans up some problematic usages of M4sh, so the

[PATCH 2/6] run sh.test on the m4sh source

This is also an independent cleanup. It is useless to play against M4sh's usage of shell syntax. We can trust M4sh to know what is doing. So, sh.test might as well be run against the pre-m4 sources. * tests/defs.m4sh (scripts): Point to pre-m4 sources. --- tests/defs.m4sh |2 +- 1 files

[PATCH 5/6] tweak order of some macros in _LT_SETUP

Another preparatory patch that executes _LT_PROG_ECHO_BACKSLASH earlier and moves the setting of *_quote_subst variables to a separate macro (which can then be AC_REQUIRE'd). --- libltdl/m4/libtool.m4 | 43 +-- 1 files changed, 25 insertions(+), 18

[PATCH 6/6] use printf as $ECHO

This is the bulk of the patch series, and it removes $ECHO in favor of `some printf' that works. This printf can be: 1) a shell builtin for the current shell; 2) a printf binary; 3) a shell builtin for another shell. There is a lot of simplification -- and more can be done because this patch

[PATCH 7/6] remove dependency on Autoconf 2.62

This patch is just a proposal, I don't really think it is needed to apply it. It removes the build dependency on Autoconf 2.62, but at the price of requiring a working `printf' to be either a builtin of a shell in the path, or the first `printf' in the path. In addition, there is some duplicate

Re: [PATCH 7/6] remove dependency on Autoconf 2.62 - postscriptum

Entire series tested with Autoconf 2.62; patches 1/6 to 6/6 tested with Autoconf git, both in a normal configuration and faking that the used printf is an external builtin printf from /bin/sh. Paolo

Re: [PATCH 1/6] Avoid that autom4te complains about unexpanded macros

Paolo Bonzini bonzini at gnu.org writes: In the meanwhile, the series cleans up some problematic usages of M4sh, so the preliminary patches can be applied independently. A disclaimer - while I am a maintainer of autoconf (and hence m4sh), I am only a contributor on libtool, and not the most

Re: [PATCH 2/6] run sh.test on the m4sh source

Paolo Bonzini bonzini at gnu.org writes: This is also an independent cleanup. It is useless to play against M4sh's usage of shell syntax. We can trust M4sh to know what is doing. So, sh.test might as well be run against the pre-m4 sources. * tests/defs.m4sh (scripts): Point to pre-m4

Re: [PATCH 3/6] use documented m4sh interfaces

Paolo Bonzini bonzini at gnu.org writes: Here we start with the meat. This patch ends Libtool's indiscriminate usage of undocumented (and in some cases deprecated) M4sh interfaces. AS_SHELL_SANITIZE is replaced with either AS_INIT or AS_INIT_GENERATED (the latter also subsumes

Re: [PATCH 6/6] use printf as $ECHO

Paolo Bonzini bonzini at gnu.org writes: This patch bumps the requirement for *building* Libtool to Autoconf 2.62, which provides a handy $as_echo which does exactly the same as we need for Libtool. However, Libtool itself uses its own echo replacement, so it is not tied to Autoconf 2.62.

Re: [PATCH] Don't install .la files when --no-la-files is used

On Thu, Nov 6, 2008 at 11:49 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Russ, * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles

Re: [PATCH] Don't install .la files when --no-la-files is used

Ralf Wildenhues [EMAIL PROTECTED] writes: Hello Russ, * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles package dependencies and makes

Xorg related problem with la files

I'm using Gentoo. In the LDFLAGS, that my system is built with, I have -Wl,--as-needed. A few days ago, there was a release of libxcb and libX11, that has done away with libxcb-xlib. The problem is that this lib has injected its la file to a lot of libX11 dependent la files. My question is: was

Re: [PATCH] Don't install .la files when --no-la-files is used

Hi Russ, Russ Allbery wrote: Ralf Wildenhues [EMAIL PROTECTED] writes: Hello Russ, * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles

Re: [PATCH] Don't install .la files when --no-la-files is used

Roumen Petrov [EMAIL PROTECTED] writes: Russ Allbery wrote: Debian's experience to date is that --as-needed is buggy and breaks a lot of software, and overall is not a particularly stable solution. Removing *.la files so that the unneeded shared libraries aren't linked in the first place