GNU bug report logs -
#19222
Some test failures with LibTool-2.4.4 on non GNU/Linux systems
Previous Next
Full log
View this message in rfc822 format
Hi Assaf,
Thanks for the reports and results.
> On Nov 30, 2014, at 1:56 AM, Assaf Gordon <assafgordon <at> gmail.com> wrote:
>
> Hello,
>
> Trying the recently released libtool-2.4.4 on non gnu/linux systems give some failures.
>
> === FreeBSD 10.0 ====
> 95: versioning FAILED (versioning.at:153)
> 169: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:48)
> ==== NetBSD 6.1.4 =====
> 55: debug tracing FAILED (help.at:159)
> 65: Link order test FAILED (link-order.at:89)
> 66: Link order of deplibs FAILED (link-order2.at:138)
> 70: static linking flags for programs FAILED (static.at:196)
> 86: deplib in subdir FAILED (deplib-in-subdir.at:126)
> 95: versioning FAILED (versioning.at:179)
> 97: DESTDIR with in-package deplibs FAILED (destdir.at:101)
> 143: C++ exception handling FAILED (exceptions.at:392)
> 164: deplibs without file command FAILED (deplibs-mingw.at:64)
> 169: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:48)
> ==== OpenBSD 5.6 ====
> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 26 27 28 29 30 31 33 34 35 36
> 38 39 40 41 42 48 49 50 51 52 98 99 100 101 102 117 118 119 120 121
> 122 123 124 125 126 127 128 129 133 134 135 144 145 146 148 149 150
> 151 161
> ==== Minix R3.3.0 ===
> 55 58 65 66 70 78 86 95 97 106 113 143 147 156 157 164 168
> ====
>
> The logs are large (including the 'testsuite.dir'), so attached are links:
> http://files.housegordon.org/libtool-2.4.4/libtool-2.4.4-freebsd10-tests.tar.gz
> http://files.housegordon.org/libtool-2.4.4/libtool-2.4.4-MinixR330-tests.tar.gz
> http://files.housegordon.org/libtool-2.4.4/libtool-2.4.4-netbsd614.tar.gz
> http://files.housegordon.org/libtool-2.4.4/libtool-2.4.4-openbsd56.tar.gz
I can see immediately that most of the failures on your OpenBSD system are caused
by not having a GNU M4 installed on the path for libtoolize. I should have been a
lot more vocal about that change rather than hiding it in the 2.4.3 release notes,
as it has tripped a lot of people up. The latest master revision now checks for a
suitable M4 at configure time, and complains if there is nothing suitable on your
command search PATH, which I think will help.
May I ask if you would kindly rerun then test suite on that machine and reply with a
link to the updated logs, after having installed GNU M4 first of course :)
I'll look into the logs of the other failing machines in the days ahead...
> No test failures on GNU-Hurd 0.5 (i386/Debian) and Mac OS X 10.9.5.
Great! Thanks :)
> Also,
> On OpenBSD 5.6, for some reason, after running "./configure", "make" tried to re-build some files using autoconf/automake - which required automake/autoconf despite this being a release tarball. Not sure if this is normal or not.
> Log:
> http://files.housegordon.org/libtool-2.4.4/openbsd56-configure-log.txt
No that's not normal, and is usually caused either by clock-skew on a network filesystem,
low clock resolution in the build filesystem (so that tar unpacks files with the same
timestamp when in fact those files were a fraction of a second apart), or even a buggy
tar program mangling the timestamps during unpack.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
This bug report was last modified 10 years and 194 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.