[PATCH 1/2] bootstrap: don't reset config-h.in timestamp newer than configure
Various autotools rules will compare the timestamps of config-h.in
and configure, and if config-h.in is newer than configure, attempt
to regenerate it. This breaks `make distcheck` which we need to
produce new releases. So update config-h.in timestamp, but only
up to the configure file.
The breakage is caught because distcheck makes source dirs read-only
before running.
$ make distcheck
...
make[3]: Entering directory '.../libtool-2.4.7.62-7132f/_build/sub'
GEN ../../libltdl/configure
autom4te-2.72: error: cannot create autom4te.cache in
.../libtool-2.4.7.62-7132f/libltdl: Permission denied
make[3]: *** [Makefile:2411: ../../libltdl/configure] Error 1
* bootstrap.conf (libtool_fudge_timestamps): Set config-h.in timestamp
to configure.
---
bootstrap.conf | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index 808321a0897b..85ac3ee19748 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -269,12 +269,17 @@ func_add_hook func_fini
libtool_readme_release_package_substitutions
# are updated. Unfortunately config-h.in depends on aclocal.m4, which
# *is* updated, so running 'libtoolize --ltdl=. && configure && make'
# causes autoheader to be called... undesirable for users that do not
-# have it! Fudge the timestamp to prevent that:
+# have it! Fudge the timestamp to prevent that. But only fudge it as
+# much as configure since configure depends on config-h.in and we don't
+# want to require autoconf either.
libtool_fudge_timestamps ()
{
$debug_cmd
-sleep 2 && touch libltdl/config-h.in
+(
+cd libltdl
+touch -r configure config-h.in
+)
}
func_add_hook func_fini libtool_fudge_timestamps
--
2.43.0
[PATCH 2/2] libtoolize: always copy config-h.in like aclocal.m4
When running `libtoolize --ltdl`, a symlink to the source config-h.in
is used rather than a copy of the file. This causes the build system
to look at its old timestamp relative to the other generated files
that are copied in, and then try to regenerate things, and update the
config-h.in timestamp by touching the symlink (which will dereference
things). This breaks `make distcheck` because when a few tests run
that invoke `libtoolize --ltdl --install` w/out --copy, and then try
to build the project, automake's rules trigger autoheader regen, and
then update the timestamp, which updates the underlying file, and then
causes libtool's own files to get out of sync. So the next time make
is run in the tree, it tries to regenerate the source files, and fails
as the source tree is read-only.
Change libtoolize to always copying the header over during install.
It's not clear to me whether this is 100% the right answer, but it
shouldn't make things worse beyond missing a case to use a symlink.
We probably can't avoid this as long as aclocal.m4 itself is copied
in instead of symlinked. This changed between v2.4.2 and v2.4.3 in
commit 4e671d6ba69c889b1f9aee12de6c504d26dc6514 ("libtoolize:
simplify file-copying and -linking call-graph.").
Example failure log:
$ make distcheck
...
make[3]: Entering directory '.../libtool-2.4.7.62-3e11/_build/sub'
GEN ../../libltdl/Makefile.in
GEN ../../libltdl/configure
autom4te-2.72: error: cannot create autom4te.cache in
.../libtool-2.4.7.62-3e11/libltdl: Permission denied
make[3]: *** [Makefile:2411: ../../libltdl/configure] Error 1
make[3]: *** Waiting for unfinished jobs
autom4te-2.72: error: cannot create autom4te.cache in
.../libtool-2.4.7.62-3e11/libltdl: Permission denied
automake-1.16: error: autoconf failed with exit status: 1
make[3]: *** [Makefile:2387: ../../libltdl/Makefile.in] Error 1
We can see this in old-m4-iface.at:AC_WITH_LTDL which doesn't use
--copy with libtoolize:
$ stat libltdl/config-h.in | grep Modify
Modify: 2024-01-18 01:18:52.998059970 -0500
$ make check-local TESTSUITEFLAGS=100
...
100: AC_WITH_LTDLok
...
$ stat libltdl/config-h.in | grep Modify
Modify: 2024-01-18 01:19:19.254727020 -0500
And in the test log we can see:
100. old-m4-iface.at:113: testing AC_WITH_LTDL ...
...
libtoolize: linking file 'libltdl/config-h.in'
...
./old-m4-iface.at:161: : ${CONFIG_SHELL=/bin/sh}; export CONFIG_SHELL;
$CONFIG_SHELL ./configure $configure_options --prefix="$prefix"
--exec-prefix="$prefix" --bindir="$prefix/bin" --libdir="$prefix/lib"
--with-included-ltdl
...
./old-m4-iface.at:161: $as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE $target
stderr:
stdout:
cd libltdl && make
make[1]: Entering directory
'/usr/local/src/gnu/libtool/tests/testsuite.dir/100/libltdl'
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal -I m4
cd . && automake --foreign
CDPATH="${ZSH_VERSION+.}:" && cd . && autoconf
/bin/sh ./config.status --recheck
...
(CDPATH="${ZSH_VERSION+.}:" && cd . && autoheader)
rm -f stamp-h1
touch config-h.in
...
* libtoolize.in: Copy config-h.in.
* tests/libtoolize.at: Change "linking" to "copying".
---
libtoolize.in | 10 +-
tests/libtoolize.at | 4 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/libtoolize.in b/libtoolize.in
index 631069418eb0..336fc81bd5ea 100644
--- a/libtoolize.in
+++ b/libtoolize.in
@@ -947,7 +947,15 @@ func_install_pkgltdl_files ()
;;
config-h.in)
- test subproject = "$ltdl_mode" || continue
+ test subproject = "$ltdl_mode" && {
+# Always copy config-h.in, otherwise automake's autoheader rules
+# will change the destination's timestamp if it is symlinked.
+( opt_copy=:
+ func_copy "$file" "$pkgltdldir" "$ltdl_dir" \
+pkgltdl_header "$my_copy_filter"
+)
+ }
+ continue
;;
configure)
diff --git a/tests/libtoolize.at b/tests/libtoolize.at
index fec51c61c5e6..cbc21d68b61d 100644
--- a/tests/libtoolize.at
+++ b/tests/libtoolize.at
@@ -471,7 +471,7 @@ libtoolize: linking file 'ltdl/README'
libtoolize: linking file 'ltdl/configure.ac'
libtoolize: copying file 'ltdl/aclocal.m4'
libtoolize: linking file 'ltdl/Makefile.in'
-libtoolize: linking file 'ltdl/config-h.in'
+libtoolize: copying file 'ltdl/config-h.in'
libtoolize: copying file 'ltdl/configure'
libtoolize: linking file 'ltdl/libltdl/lt__alloc.h'
libtoolize: linking file 'ltdl/libltdl/lt__argz_.h'
@@ -1047,7 +1047,7 @@ libtoolize: linking file 'ltdl/README'
libtoolize: creating file 'ltdl/configure.ac'
libtoolize: creating file 'ltdl/aclocal.m4'
libtoolize: creating file 'ltdl/Makefile.in'
-libtoolize: linking file 'ltdl/config-h.in'
+libtoolize: copying file 'ltdl/config-h.in'
libtoolize: creating file 'ltdl/configure'
libtoolize: linking file 'ltdl/libltdl/lt__alloc.h'
libtoolize: linking file
[PATCH] HACKING: add more test related tips
* HACKING: Document syntax-check & distcheck & parallel testing. --- HACKING | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/HACKING b/HACKING index 664251e680a9..38401c9cd732 100644 --- a/HACKING +++ b/HACKING @@ -24,6 +24,14 @@ and is not part of a release distribution. that demonstrates the bug. Then fix the bug, re-run the test suite, and check everything in. +* Always run the testsuite after applying a patch: +make check syntax-check TESTSUITEFLAGS="--jobs=$(nproc)" -j$(nproc) + + Ideally also verify the release process doesn't break: +make distcheck TESTSUITEFLAGS="--jobs=$(nproc)" -j$(nproc) + This will run check & syntax-check from above, but will take longer as + builds & tests in different configurations. + * Some files in the libtool package are not owned by libtool. These files should never be edited here. These files are: COPYING @@ -55,13 +63,17 @@ and is not part of a release distribution. AT_CHECK) is on a single line so that 'testsuite -x' displays the whole thing. You can use m4_do or '[... ]dnl' to wrap long lines. -* Use -make -k check +* Run tests in parallel with +make -k check TESTSUITEFLAGS="--jobs=$(nproc)" liberally, on as many platforms as you can. Use as many compilers and linkers you can. To run old and new testsuites separately, use: make check TESTSUITEFLAGS=-V make check-local +* The gnulib module also provides some maintainer-focused tests that only + work when run from a git checkout. +make syntax-check + * The new Autotest testsuite uses keywords to denote test features: autoconf needs Autoconf automake needs Automake -- 2.43.0
Re: [PATCH 2/3] ltmain.in: Parse additional clang options
On 17 Jan 2024 12:39, Richard Purdie wrote: > clang uses -rtlib and --unwindlib to select proper compiler runtime in > some cases. Therefore pass these options to linker when found in > ldflags merged, thanks -mike signature.asc Description: PGP signature
Re: [PATCH 3/3] libtool.m4: Cleanup sysroot trailing "/"
On 17 Jan 2024 12:39, Richard Purdie wrote: > If $CC has --sysroot=/, it is a valid configuration however libtool will > then set lt_sysroot to "/". > > This means references like $lt_sysroot$libdir become //usr/lib instead > of the more normally expected /usr/lib. This may or may not break something > but certainly is confusing to the user and gives confusing output. Making > "/" simply unset lt_sysroot is much cleaner. > > Whilst here, trim any trailing '/' from sysroot paths to drop the duplication > and result in cleaner/consistent output. merged, thanks -mike signature.asc Description: PGP signature
Re: [PATCH 1/3] ltmain.in: Handle prefix-map compiler options correctly
On 17 Jan 2024 12:39, Richard Purdie wrote: > If lto is enabled, we need the prefix-map variables to be passed to the linker > to correctly link the objects using correctly mapped paths. > > Add these to the list of options libtool passes through. merged, thanks -mike signature.asc Description: PGP signature
Re: [PATCH 1/3] libtool.m4: augment symcode for Solaris 11
On 17 Jan 2024, Mike Frysinger told this: > this should be fixed in git now. i merged the one posted previously: > https://savannah.gnu.org/patch/?9086 Truly, the dead walk! (Thank you.) (There are a few related problems on other architectures I've fixed in the binutils copy of libtool.m4 too -- I think I posted them to the list lo these many years ago as well.) -- NULL && (void)
Re: patch to correct fallout from freebsd-elf changes
On 18 Jun 2017 19:43, Tim Rice wrote: > Here is a small patch to correct builds on svr5. > When the freebsd-elf target was changed, this got missed. > > Symptoms were, build newer lib ened up with libfo.nn a loser number > than the previous version. And building libpng-1.6.29 produced > libtool: error: CURRENT '' must be a nonnegative integer > libtool: error: '16:29:0' is not valid version information > > Patch attached and inline here. merged, thanks. in the future, please make & send standard git commits instead. when you attach patches, it makes things difficult for us to merge. -mike signature.asc Description: PGP signature
Re: patch to correct fallout from freebsd-elf changes
[original post: https://lists.gnu.org/archive/html/libtool-patches/2017-06/msg0.html] With all the flurry of commits I'm hoping this gets included. [And gives me a chance to correct all the embarrassing typos in the body of the original message] Thanks. On Sun, 18 Jun 2017, Tim Rice wrote: > > Here is a small patch to correct builds on svr5. > When the freebsd-elf target was changed, this got missed. > > Symptoms were, building newer lib ended up with libfoo.nn a lower number > than the previous version. And building libpng-1.6.29 produced > libtool: error: CURRENT '' must be a nonnegative integer > libtool: error: '16:29:0' is not valid version information > > Patch attached and inline here. > > diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in > index bbc7643..d3ee94f 100644 > --- a/build-aux/ltmain.in > +++ b/build-aux/ltmain.in > @@ -6919,7 +6919,7 @@ func_mode_link () > age=$number_minor > revision=$number_revision > ;; > - freebsd-aout|qnx|sunos) > + freebsd-aout|qnx|sco|sunos) > current=$number_major > revision=$number_minor > age=0 > > -- Tim RiceMultitalents t...@multitalents.net diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index bbc7643..d3ee94f 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -6919,7 +6919,7 @@ func_mode_link () age=$number_minor revision=$number_revision ;; - freebsd-aout|qnx|sunos) + freebsd-aout|qnx|sco|sunos) current=$number_major revision=$number_minor age=0
Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs
On Wed, 17 Jan 2024, Roumen Petrov wrote: Hi All Mike Frysinger wrote: On 16 Jan 2024 21:11, Brad Smith wrote: libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago. This cannot be reason to drop support. For instance RHEL was release in 2011 and is still supported. This seems like a strong argument, but there are other factors. A strong reason to stop supporting a target/version is if it's existence interferes with maintenance/development and there is no reasonable means available to verify that the support still works. Support which is not periodically tested likely does not work any more. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: > On 16 Jan 2024 23:44, KO Myung-Hun wrote: >> Some OSes such as OS/2, uses ';' as a path separator. So using >> $PATH_SEPARATOR instead of hard-coded ':' is more proper. > > so we're on the same page, we're talking about the separator that > is used in the $PATH environment variable. it doesn't show up in > other places -- it is not used to separate e.g. rpath entries right > ? what about LD_LIBRARY_PATH and similar vars ? i guess we assume > the separator used by PATH is also used with that var ? This is applied to all the variables containing a list of paths and/or dirs separated by ':' including PATH and LD_LIBRARY_PATH. If rpath entries is separated by ':', it's also true. - -- KO Myung-Hun Korean OS/2 User Community : https://www.os2.kr/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (OS/2) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFlp9m6E9YstvghgroRAqRsAKCpMU2R0Ci96WrlxC4v3MeDSnJBlACgtwJo sb+xmV5nLYLHccbW8uJl4W8= =FtDX -END PGP SIGNATURE-
[PATCH 2/3] ltmain.in: Parse additional clang options
clang uses -rtlib and --unwindlib to select proper compiler runtime in
some cases. Therefore pass these options to linker when found in
ldflags
* build-aux/ltmain.in: Handle clang linker options
---
build-aux/ltmain.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 5b59d959..8a832a47 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5413,12 +5413,14 @@ func_mode_link ()
# -shared-libsan Link with shared sanitizer runtimes (Clang)
# -static-libsan Link with static sanitizer runtimes (Clang)
# -fuse-ld=* Linker select flags for GCC
+ # -rtlib=* select c runtime lib with clang
+ # --unwindlib=*select unwinder library with clang
# -f{file|debug|macro|profile}-prefix-map* needed for lto linking
# -Wa,*Pass flags directly to the assembler
# -Werror, -Werror=* Report (specified) warnings as errors
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
-
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
+
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*|-rtlib=*|--unwindlib=*|
\
-specs=*|-fsanitize=*|-fno-sanitize*|-shared-libsan|-static-libsan| \
-ffile-prefix-map=*|-fdebug-prefix-map=*|-fmacro-prefix-map=*|-fprofile-prefix-map=*|
\
-fdiagnostics-color*|-frecord-gcc-switches| \
--
2.39.2
[PATCH 1/3] ltmain.in: Handle prefix-map compiler options correctly
If lto is enabled, we need the prefix-map variables to be passed to the linker
to correctly link the objects using correctly mapped paths.
Add these to the list of options libtool passes through.
* build-aux/ltmain.in: Handle prefix-map compiler options
---
build-aux/ltmain.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 830b3982..5b59d959 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5413,12 +5413,14 @@ func_mode_link ()
# -shared-libsan Link with shared sanitizer runtimes (Clang)
# -static-libsan Link with static sanitizer runtimes (Clang)
# -fuse-ld=* Linker select flags for GCC
+ # -f{file|debug|macro|profile}-prefix-map* needed for lto linking
# -Wa,*Pass flags directly to the assembler
# -Werror, -Werror=* Report (specified) warnings as errors
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-specs=*|-fsanitize=*|-fno-sanitize*|-shared-libsan|-static-libsan| \
+
-ffile-prefix-map=*|-fdebug-prefix-map=*|-fmacro-prefix-map=*|-fprofile-prefix-map=*|
\
-fdiagnostics-color*|-frecord-gcc-switches| \
-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
func_quote_arg pretty "$arg"
--
2.39.2
[PATCH 3/3] libtool.m4: Cleanup sysroot trailing "/"
If $CC has --sysroot=/, it is a valid configuration however libtool will then set lt_sysroot to "/". This means references like $lt_sysroot$libdir become //usr/lib instead of the more normally expected /usr/lib. This may or may not break something but certainly is confusing to the user and gives confusing output. Making "/" simply unset lt_sysroot is much cleaner. Whilst here, trim any trailing '/' from sysroot paths to drop the duplication and result in cleaner/consistent output. * m4/libtool.m4: Cleanup sysroot trailing '/' handling --- m4/libtool.m4 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index ed572bb3..f2532f0e 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1255,7 +1255,9 @@ lt_sysroot= case $with_sysroot in #( yes) if test yes = "$GCC"; then - lt_sysroot=`$CC --print-sysroot 2>/dev/null` + # Trim trailing / since we'll always append absolute paths and we want + # to avoid //, if only for less confusing output for the user. + lt_sysroot=`$CC --print-sysroot 2>/dev/null | $SED 's:/\+$::'` fi ;; #( /*) -- 2.39.2
Re: [PATCH 1/3] ltmain.in: Handle prefix-map compiler options correctly
On Tue, 2024-01-16 at 20:47 -0500, Mike Frysinger wrote:
> On 16 Jan 2024 15:14, Richard Purdie wrote:
> > --- a/build-aux/ltmain.in
> > +++ b/build-aux/ltmain.in
> > @@ -7,7 +7,6 @@
> > # Copyright (C) 1996-2019, 2021-2024 Free Software Foundation, Inc.
> > # This is free software; see the source for copying conditions. There is
> > NO
> > # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > -
> > # GNU Libtool is free software; you can redistribute it and/or modify
> > # it under the terms of the GNU General Public License as published by
> > # the Free Software Foundation; either version 2 of the License, or
>
> let's leave unrelated changes out please
Sorry.
>
> > @@ -5413,12 +5412,14 @@ func_mode_link ()
> ># -shared-libsan Link with shared sanitizer runtimes (Clang)
> ># -static-libsan Link with static sanitizer runtimes (Clang)
> ># -fuse-ld=* Linker select flags for GCC
> > + # -f{file|debug|macro}-prefix-map* needed for lto linking
>
> these take the form of -ffile-prefix-map=xxx right ?
Yes. There was talk of a 'read from file' version but that doesn't look
like it was merged anywhere.
> so we'd want to put a = before the glob at the end ?
Sure. I'll also add profile-prefix-map for completeness since it looks
like the naming debate was settled on that one and it was merged (I
personally don't need it).
Cheers,
Richard
Re: [patch #10393] Fix shared library support on Android
Hi Bruno, Bruno Haible wrote: Roumen Petrov wrote: Android and Microsoft windows must not encode any paths. You probably mean to say: Shared libraries packaged in Android .apk files are mentioned in the Android manifest file (elements and ) [1] and therefore don't need a RUNPATH. But shared libraries created in the Termux environment are a different case, and they do need a RUNPATH, as I explained in the previous mail. RUNPATH or another section. So far so good but not all loaders support all features elf format. You cannot use one particular sample to dictate for all others. On top of this run-paths are again rules on some above mentioned OS-es. On those operation system shared libraries could be installed anywhere. When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries and executable could run in any Android profile. The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus". PKIX-SSH binaries use ldns as resolver library. This library uses libtool. Again: If you want a certain binary that you build to have no RUNPATH, use the Android SDK, not Termux and not libtool. Or use libtool outside of Termux and don't provide a -R option. There is nothing related to the way how binaries are created by high level build environment. You cannot dictated how to build binaries. I use standard build provided by project. This is reason do not understand you point here. You environment is with "hard-coded" paths. I mean at least prefix. I cannot understand why you build does not use -Xlinker (please check libtool documentation for exact name) to specify run-time paths. You environment is specific and does not fulfill Android requirements. Libtool is general purpose build system and so must follow OS-requirement. General build system cannot follow wish list of a developer in environment with hard-coded locations. This is reason Termux application to fail to run in other Android profile. Termux is a good sample for broken Android application. Libtool must not follow builds in environment broken by design. Also to ensure that binaries runs on support API levels elf-cleaner is should be run to "strip" certain sections. You mean [2] or [3]? I think this is out of scope for libtool, because: - As far as I understand, it applies to both shared libraries and executables, and since executables can be created without using libtool, the right place to invoke these tools are not in libtool. - As you say, it depends on the minimum supported Android API level, which is a priori known to the Makefile and to the compiler (via '-target' options), but not known to libtool. Related to functionality supported by Android loader. If you would like to distribute binaries clean of some section is strongly recommended. But if build is for fun please pass to the linker specific paths. As pointed above you environment is with hard-coded location i.e., it is easy to set linker options. Bruno Roumen
