1

TL,DR:

Is there a way for me (no root access) to make the linker (invoked by gcc) unaware of the contents of a directory contained in /etc/ld.so.conf after it has been cached via ldconfig?

In Detail:

I'm trying (and failing) to compile HTCondor on a custom linux distro without root access. For various reasons (see below) I believe that the problems I encounter are related to the fact that there are two versions of libssl and two versions of libcrypto installed on this machine. The newer version (1.0.0) of each of these is located at /usr/lib64 and an older version (0.9.8) is kept at /usr/local/lib64 for compatibility reasons. /etc/ld.so.conf contains both of these paths, so the linker knows about both.

During compilation I get an error

../condor_utils/libcondor_utils_8_7_9.so: undefined reference to `ERR_remove_thread_state'

since, for some reason, libcondor_utils_8_7_9.so is linked against libcrypto.so.0.9.8, while ERR_remove_thread_state was introduced in 1.0.0. It appears exactly once in the source code:

#if OPENSSL_VERSION_NUMBER < 0x10000000L
    ERR_remove_state( 0 );
#elif OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
    ERR_remove_thread_state( 0 );
#endif

so the preprocessor seems to make its decision based on version 1.0.0.

This question made me aware of this blog post, so I tried surrogating cpp with the following script:

#!/bin/bash
/usr/bin/gcc -Wl,-rpath-link="/usr/lib64",-rpath="/usr/lib64" "$@"

to no avail, unfortunately.

Just for the heck of it, I also tried commenting the prepocessor directives in the source code snippet above to force the selection of ERR_remove_state. This results in the linker warning me that libssl.so.1.0.0 may conflict with libssl.so.0.9.8 and, unsurprisingly, produces another "undefined reference" error.

EDIT:

The problem turned out not to be related to the linker at all. See my answer. However, out of curiosity, I'll leave the question open to see if anyone has a solution for it in its original formulation.

user35915
  • 1,222
  • 3
  • 17
  • 23
  • 2
    when linking you can pass the absolute path for the individual libs – 463035818_is_not_an_ai Oct 15 '18 at 14:10
  • @user463035818 oh man. That's probably a solution. Completely forgot about it. Will try and let you know. Thanks. – user35915 Oct 15 '18 at 14:13
  • *"`libcondor_utils_8_7_9.so` is linked against `libcrypto.so.0.9.8`..."* - Please file a bug report against Condor. OpenSSL 0.9.8 is ancient, and has too many problems to spend time detailing. It should have failed acceptance testing at your organization :o – jww Oct 16 '18 at 08:38
  • I think you should rewind a bit and show how you are compiling and linking your libraries and programs. We need to see the actual arguments to the compiler and linker. LD will happily link against the wrong libraries at runtime. You may get lucky and be able to build your app with RPATHs. That is, linker options `-Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags`. You need to use them both, and be sure to compile with `-I /usr/local/include` and link with `-L /usr/local/lib64`. – jww Oct 16 '18 at 08:44
  • @user463035818 you had the right idea. See my answer. – user35915 Oct 16 '18 at 14:08
  • @jww good point. No idea why Condor can still be linked against 0.9.8. And will also ask the admins here why exactly they're still keeping it around. It was never my intention, though, to link against it. The two versions just seem to be getting mixed up by the Condor build system. – user35915 Oct 16 '18 at 14:08
  • @jww rewinding was a good point. See my answer. – user35915 Oct 16 '18 at 14:09

1 Answers1

0

The comments by @user463035818 and @jww pointed me in the right direction to solve my specific problem, which turned out not be related to the linker directly.

Condor uses cmake as build system, so obviously it makes more sense to try to solve this at the cmake level (n00b here). Somewhere in the depths of all the things cmake does it finds both versions of the libraries and mixes them up for some reason. Invoking find_library with a specific version as per this answer in the main CMakeLists.txt solves that problem although it leaves a bad taste of dirty workaround in my mouth.

Making cmake ignore a certain directory when looking for libraries should not be hard, according to the docs. I haven't tried it, though.

user35915
  • 1,222
  • 3
  • 17
  • 23