Re: libtasn1 2.11 pre-release

[Simon Josefsson]

Bruno Haible <address@hidden> 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