cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: curl-7.36.0 TESTFAIL: These test cases failed: 815 816 1513

From: Dan Fandrich <dan_at_coneharvesters.com>
Date: Thu, 3 Apr 2014 08:59:40 +0200

On Wed, Apr 02, 2014 at 11:53:13AM -0400, dev wrote:
> I wanted to follow up on a previous email because I thought you had seen
> something seriously wrong in my build config.

Not seriously wrong, just possibly slightly sub-optimal.

> > > okay .. will do and I'll see what I see. I will just try to run
> > > lib1513
> > > but there is a LOT going on :
> > >
> > > node002$ ldd ./tests/libtest/.libs/lib1513
> > > libcurl.so.4 => /usr/local/lib/libcurl.so.4
> > > libidn.so.11 => /usr/local/lib/libidn.so.11
> > > libintl.so.8 => /usr/local/lib/libintl.so.8
> > > libc.so.1 => /lib/64/libc.so.1
> > > libiconv.so.2 => /usr/local/lib/libiconv.so.2
> > > libssh2.so.1 => /usr/local/lib/libssh2.so.1
> > > libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0
> >
> > This is OpenSSL.
>
> yep.
>
> >
> > > libcrypto.so.1.0.0 =>
> > > /usr/local/ssl/lib/libcrypto.so.1.0.0
> > > libldap.so.5 => /usr/lib/64/libldap.so.5
> > > libz.so.1 => /usr/local/lib/libz.so.1
> > > librt.so.1 => /lib/64/librt.so.1
> > > libsocket.so.1 => /lib/64/libsocket.so.1
> > > libnsl.so.1 => /lib/64/libnsl.so.1
> > > libdl.so.1 => /lib/64/libdl.so.1
> > > libsasl.so.1 => /usr/lib/64/libsasl.so.1
> > > libmd.so.1 => /lib/64/libmd.so.1
> > > libnspr4.so => /usr/lib/mps/64/libnspr4.so
> > > libplc4.so => /usr/lib/mps/64/libplc4.so
> > > libnss3.so => /usr/lib/mps/64/libnss3.so
> >
> > And this is NSS. Looks like things aren't configured optimally on
> > this build.
>
> This is where I stopped and said "oh?"
>
> I have to build curl/libcurl for a production environment and therefore
> I keep logs of what I do on my build server. So I have logs going back
> about a year :
[...]
> node002$ cat curl-7.36.0_SunOS5.10_sparcv9.001.config.log
> $ ./configure --enable-shared --enable-static --with-libidn=/usr/local \
> > --enable-tls-srp --with-ssl --with-gnutls=/usr/local \
> > --with-ca-path=/usr/local/ssl/certs

This configure line is a bit ambiguous, for historical reasons. --with-ssl
actually means with OpenSSL, and OpenSSL is what configure uses. If you want
GnuTLS, you actually need --without-ssl --with-gnutls=/usr/local, or better
yet, --without-ssl --with-gnutls and set PKG_CONFIG_PATH if necessary to pick
up the GnuTLS pkg-config configuration. What's strange is that your ldd lines
above show NSS being used. It might be because it's not picking up the libcurl
you think it is.

> > Something (probably libcurl itself) is using libnss, and something
> > else
> > (probably libssh2) is using OpenSSL. There's nothing really wrong with
> > that
> > except that there are two crypto libraries involved with two different
> > ways of
> > configuring things, and which way depends on the protocol used by
> > libcurl.
> > Ideally, you could make do with only a single crypto library but
> > libssh2
> > doesn't support NSS so if you insist on NSS for libcurl, you're stuck
> > with it.
>
> I am trying to figure out if this is a "good" thing or not. What I have
> done in the past has worked really well and libCurl is linked in with
> other software pieces of course and they all run great.

It will work fine, and there's nothing wrong with it if you understand the
implications.

> However, and this is a big fat "however", I don't want my nightly builds
> to mess up results for the project. Therefore I need to sort out what
> is reasonable for nightly builds.
>
> Make sense?

The combination of mixing different SSL libraries should operate fine in the
test suite. If you can set up some autobuilds in that configuration, it would
still be a big help.

> If you see something above that is clearly not quite right, let me know.
>
> > > libssl3.so => /usr/lib/mps/64/libssl3.so
> > > libaio.so.1 => /lib/64/libaio.so.1
> > > libmp.so.2 => /lib/64/libmp.so.2
> > > libscf.so.1 => /lib/64/libscf.so.1
> > > libpthread.so.1 => /lib/64/libpthread.so.1
> > > libnssutil3.so => /usr/lib/mps/sparcv9/libnssutil3.so
> > > libplds4.so => /usr/lib/mps/sparcv9/libplds4.so
> > > libthread.so.1 => /lib/64/libthread.so.1
> > > libdoor.so.1 => /lib/64/libdoor.so.1
> > > libuutil.so.1 => /lib/64/libuutil.so.1
> > > libgen.so.1 => /lib/64/libgen.so.1
> > > libm.so.2 => /lib/64/libm.so.2
> > > /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
> > > /platform/SUNW,T5240/lib/sparcv9/libmd_psr.so.1
> > >
> > > Should be fun.
> >
> > It's easy it using the test harness: "make test TEST_Q='-g 1513'" will
> > configure the test harness and start the test program using gdb.
>
> Sadly gdb on Solaris is never an easy thing to deal with. I have dbx
> from Oracle Studio 12.3 to single step around and breakpoint with.

You could create a gdb wrapper around dbx to spawn dbx instead when the test
suite calls it, or have the wrapper call "sleep 9999" which would give you a
chance to start dbx manually using the options that gdb would have used.
It would be very tricky to start all the test servers you need for each test
manually, which is why -g is the only reasonable way to run most tests in the
test suite under a debugger.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-04-03