shared libraries vs test cases

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

shared libraries vs test cases

Michael Richardson
Running LDD on the binaries in test/* shows that they appear to link against
the "system" copies of libssl and libcrypto.

Perhaps something I'm missing is setting up LD_PRELOAD or some such so that
the tests run the local copy of libssl/libcrypto, but I can't find that.
Am I missing something?

This is, I think, making it very difficult for me to bisect a problem.

It seems to me that the test cases ought to be statically linked to make
it easiest to know what code they are running.  (This also makes it slightly
easier to use gdb on them)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


Reply | Threaded
Open this post in threaded view
|

Re: shared libraries vs test cases

Viktor Dukhovni
> On Feb 27, 2019, at 11:04 AM, Michael Richardson <[hidden email]> wrote:
>
> Running LDD on the binaries in test/* shows that they appear to link against
> the "system" copies of libssl and libcrypto.

With no environment overrides of LD_LIBRARY_PATH or similar, the test cases
in the build tree are expected to find the OpenSSL libraries in the install
target location (if on the default system search path) or when you compile
with "-R", "-rpath" or similar.  So the output of ldd is not surprising.

The tests run with LD_LIBRARY_PATH settings via util/shlib_wrap.sh

> This is, I think, making it very difficult for me to bisect a problem.
>
> It seems to me that the test cases ought to be statically linked to make
> it easiest to know what code they are running.  (This also makes it slightly
> easier to use gdb on them)

The test cases exercise the code the same way it is going to be used.
You can do a "no-shared" build if you like, but then some features
that depend on dynamic linking/loading may not be available.  If you're
just trying to bisect a problem, that may be acceptable...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: shared libraries vs test cases

Richard Levitte - VMS Whacker-2
In reply to this post by Michael Richardson
On Wed, 27 Feb 2019 17:04:09 +0100,
Michael Richardson wrote:

>
> Running LDD on the binaries in test/* shows that they appear to link against
> the "system" copies of libssl and libcrypto.
>
> Perhaps something I'm missing is setting up LD_PRELOAD or some such so that
> the tests run the local copy of libssl/libcrypto, but I can't find that.
> Am I missing something?
>
> This is, I think, making it very difficult for me to bisect a problem.
>
> It seems to me that the test cases ought to be statically linked to make
> it easiest to know what code they are running.  (This also makes it slightly
> easier to use gdb on them)

There's a script called util/shlib_wrap.sh that you place first on the
command line:

./util/shlib_wrap.sh test/whatevertest

./util/shlib_wrap.sh ldd test/whatevertest

./util/shlib_wrap.sh gdb test/whatevertest

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: shared libraries vs test cases

OpenSSL - User mailing list
In reply to this post by Michael Richardson
On 27/02/2019 17:04, Michael Richardson wrote:

> Running LDD on the binaries in test/* shows that they appear to link against
> the "system" copies of libssl and libcrypto.
>
> Perhaps something I'm missing is setting up LD_PRELOAD or some such so that
> the tests run the local copy of libssl/libcrypto, but I can't find that.
> Am I missing something?
>
> This is, I think, making it very difficult for me to bisect a problem.
>
> It seems to me that the test cases ought to be statically linked to make
> it easiest to know what code they are running.  (This also makes it slightly
> easier to use gdb on them)
>
In builds that produce shared libraries, those shared libraries
(and not a similar-but-different static library) is what needs to
be tested.

That said, it would be beneficial if the build system set the
appropriate linker flags to make the test programs (but not the
user programs such as PREFIX/bin/openssl{.exe,}) link to the
shared library in the build tree whenever the target allows
this.

Some examples:

- Windows(all versions): This is already the system default
  if the shared libraries are copied into the test program
  directory, even in Windows versions that don't search the
  current directory at invocation (which is often different
  from the program directory). However some very old Windows
  versions will only search the launch-time current dir.

- For many other targets, the -rpath option will do this
  for local runs of the tests, while for cross-compiled
  tests (for testing on hardware without local compilation),
  a more careful -rpath value is needed to reference the
  test dir on the target, not the host.

As a further improvement, where possible, the inter-library
references and the reference from the user programs compiled
from the OpenSSL source should somehow tie themselves to the
exact shared library versions used, e.g. by linking to
versioned .so file names (such as libssl.so.3.0.2), however
this does not protect recompiling and/or debugging with an
unchanged .so name.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: shared libraries vs test cases

Michael Richardson
In reply to this post by Richard Levitte - VMS Whacker-2

Richard Levitte <[hidden email]> wrote:
    >> Running LDD on the binaries in test/* shows that they appear to link against
    >> the "system" copies of libssl and libcrypto.
    >>
    >> Perhaps something I'm missing is setting up LD_PRELOAD or some such so that
    >> the tests run the local copy of libssl/libcrypto, but I can't find that.
    >> Am I missing something?
    >>
    >> This is, I think, making it very difficult for me to bisect a problem.
    >>
    >> It seems to me that the test cases ought to be statically linked to make
    >> it easiest to know what code they are running.  (This also makes it slightly
    >> easier to use gdb on them)

    > There's a script called util/shlib_wrap.sh that you place first on the
    > command line:

    > ./util/shlib_wrap.sh test/whatevertest

    > ./util/shlib_wrap.sh ldd test/whatevertest

    > ./util/shlib_wrap.sh gdb test/whatevertest

And another email says that this is done by default for "make test".

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment