Bruno Haible <[email protected]> writes: > Hi Simon, > >> http://daily.josefsson.org/libtasn1/libtasn1-2.11.tar.gz > > * Linux/MIPS (in 32-bit, n32, and 64-bit modes) > * Linux/SPARC (both 32-bit and 64-bit) > * Linux/HP-PA > * Linux/IA-64 > * MacOS X 10.5 (both 32-bit and 64-bit) > * FreeBSD 6.4 > * NetBSD 5.1 > * OpenBSD 4.9 > * AIX 5.1 > * AIX 7.1 > * HP-UX 11.00 > * IRIX 6.5 > * OSF/1 5.1 > * Solaris 7 > * Solaris 8 > * Solaris 9 > * Cygwin 1.7.9 > * mingw with gcc > > All 8 tests passed.
Hi Bruno, thanks for testing! That is an impressive number of systems. > * Linux/x86_64 > > 8 of 8 tests failed > > The reason is that I have valgrind 3.5.0 installed, and "make check" > apparently > runs valgrind on many 'bash' processes, each leading to a failure. See > attached > log. Can you try and run this for me on that system: valgrind -q --error-exitcode=1 --leak-check=no /bin/bash -c 'exit 0' echo $? Currently valgrind-tests checks whether running 'valgrind -q true' works, and then enables valgrind. I'm considering changing valgrind-tests.m4 into testing that 'valgrind $SHELL -c "exit 0"' works. However, looking more closely at the output, only for the crlf and threadsafety are valgrind inspecting bash. Look at the Test_simple output for example, there are three issues that looks like a system issue that applies to any newly compiled prorgram. Hopefully the command above fails on that system, although in theory it may not -- and the right thing would be to compile a short known valgrind free program and check whether valgrind accepts it, and only then enable valgrind. This may be too much work though. > * mingw with MSVC 9 as compiler > > Build failure: > > CCLD libtasn1.la > cl : command line warning D9002 : unknown option > "--version-script=./libtasn1.map", ignoring > cl : command line warning D9002 : unknown option "-dll", ignoring > LINK : fatal error LNK1181: input file "ink.lib" cannot be opened > make[3]: *** [libtasn1.la] error 2 > > config.status contains this: > S["HAVE_LD_VERSION_SCRIPT_FALSE"]="#" > S["HAVE_LD_VERSION_SCRIPT_TRUE"]="" > > configure's output contains this: > checking if LD -Wl,--version-script works... yes > > The reason is apparently that $CC = "$HOME/msvc/compile cl -nologo" > accepts and ignores the -Wl,--version-script option. Whereas when you use > CCLD, it uses libtool, and libtool trims off the prefix "-Wl," from this > option and passes --version-script to the linker (also $CC). > > The bottom line is that before trying -Wl (in gnulib/m4/ld-version-script.m4) > one should first test whether -Wl is the linker option prefix at all. > Cf. libtool.m4 and gnulib/build-aux/config.rpath. I'll need to think more about how to handle this one. However since there are workarounds -- 1) use --disable-ld-version-script or 2) use MSVC project files available in windows/ -- and it is not a regression since earlier releases, I'm leaning towards not delaying the release over this. /Simon
