15.4.2014 11:37, Sahib Jakhar kirjoitti:
Hi,
We have a build machine where two versions of libssl exist (one of
them custom built - against which we want to link). However, no matter
what we try, it is linking against the system's libssl.
Not caring to investigate what you did "wrong", here is the usual
practice...
There is a quite well-known solution for using custom shared libraries
instead
of the ones provided by the system's standard C library etc. And that
is using
the '-rpath' option during linking to tell where the custom libraries are :
-rpath dir
Add a directory to the runtime library search path. This is used when
linking an
ELF executable with shared objects. All `-rpath' arguments are concatenated
and passed to the runtime linker, which uses them to locate shared
objects at
runtime. The `-rpath' option is also used when locating shared objects which
are needed by shared objects explicitly included in the link; see the
description
of the `-rpath-link' option. If `-rpath' is not used when linking an ELF
executable, the contents of the environment variable LD_RUN_PATH will be
used
if it is de ned.
Every newbie of course also learns how to add linker options onto the
'gcc' command
line. Even the 'gcc --help' command will show this, no need to consult
the nice GCC
manual. So one uses the '-Wl, <linker_option>', replacing spaces with
commas :
-Wl,option
Pass option as an option to the linker. If option contains commas,
it is split
into multiple options at the commas.
