[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19893: GNU libtool-2.4.6 released [stable]

From: Michael Felt
Subject: bug#19893: GNU libtool-2.4.6 released [stable]
Date: Wed, 18 Feb 2015 09:18:51 +0100

Build proceeded without incident - running make check returns some errors - but maybe these are with the test, not libtool.

Test 70, e.g., proceeds fine but at line 61 - it fails - after having done the hard work perhaps, and I suspect because $GREP is not defined

in the test file runpath-in-lalib.at

   +61  AT_CHECK([$GREP /foobar $libdir/liba.la], [], [ignore])
   +62  AT_CHECK([$GREP /foobar $libdir/libb.la], [], [ignore])
   +64  # TODO: check that m gets -R, too.
   +66  AT_CLEANUP

In the log file:
./runpath-in-lalib.at:59: $LIBTOOL --mode=install cp m$EXEEXT $bindir/m$EXEEXT
libtool: install: cp .libs/m /data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.d
./runpath-in-lalib.at:61: $GREP /foobar $libdir/liba.la
./runpath-in-lalib.at:61: exit code was 1, expected 0
70. runpath-in-lalib.at:25: 70. Runpath in libtool library files (runpath-in-lalib
.at:25): FAILED (runpath-in-lalib.at:61)

Two questions:

1. the word [ignore] at the end does not mean to ignore exit status - I am guessing. So what does it mean?
2. How can I easily run a (verbose) single-test (and maybe have it echo the values of things like $GREP)

I am running the tests against 'coreutils' rather than standard AIX - I should (and will) repeat the tests without coreutils - maybe even 'real soon' rather than eventually :)
address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests]type cp
cp is a tracked alias for /opt/bin/cp
address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests]type install
install is /opt/bin/install

I mention (and do) this because AIX /usr/bin/install (and even the AIX /usr/bsd/install) fail sometimes (with some projects, e.g. httpd).

On Sun, Feb 15, 2015 at 10:03 PM, Gary V. Vaughan <address@hidden> wrote:

The Libtool Team is pleased to announce the release of libtool 2.4.6.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

This is a bugfix release, and a recommended upgrade for all users.  Most
importantly, it regains most of the speed of 2.4.2 by correcting one of
two known regressions that were causing noticable slow-down when building
projects with many source files.

Here are the compressed sources:
  http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz   (1.7MB)
  http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.xz   (952KB)

Here are the GPG detached signatures[*]:

Use a mirror for higher download bandwidth:

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify libtool-2.4.6.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 151308092983D606

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.15
  Gnulib v0.1-336-g342d9f0


* Noteworthy changes in release 2.4.6 (2015-02-15) [stable]

** New features:

  - LT_SYS_LIBRARY_PATH can be set in config.site, or at configure time
    and persists correctly in the generated libtool script.

** Bug fixes:

  - Fix a race condition in ltdl dryrun test that would cause spurious
    random failures of that test.

  - LT_SYS_DLSEARCH_PATH is munged correctly.


If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]