shared libraries vs test cases

[Jakob Bohm]

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