Reg solaris support for openssl 1.1.1b
dclarke at blastwave.org
Tue Mar 19 07:40:31 UTC 2019
On 3/19/19 4:38 AM, ramakrushna mishra wrote:
> Hi All,
> Thanks for all your response.
> I have tried to set LD_LIBRARY_PATH to the lib path of newly installed
> openssl and still "./openssl version" fails with the same reason.
right out of the ld man page we see the option -R passed to the linker :
A colon-separated list of directories used to specify
library search directories to the runtime linker. If
present and not NULL, the path is recorded in the output
object file and passed to the runtime linker. Multiple
instances of this option are concatenated together with
each path separated by a colon. See Directories Searched
by the Runtime Linker in Linker and Libraries Guide.
The use of a runpath within an associated object is
preferable to setting global search paths such as
through the LD_LIBRARY_PATH environment variable. Only
the runpaths that are necessary to find the objects
dependencies should be recorded. ldd(1) can also be used
to discover unused runpaths in dynamic objects, when
used with the -U option.
Various tokens can also be supplied with a runpath that
provide a flexible means of identifying system capabili-
ties or an objects location. See Chapter 6, Establishing
Dependencies with Dynamic String Tokens, in Linker and
Libraries Guide. The $ORIGIN token is especially useful
in allowing dynamic objects to be relocated to different
locations in the file system.
So that works. Alos there is a note about the dreaded :
A list of directories in which to search for the
libraries specified using the -l option. Multiple direc-
tories are separated by a colon. In the most general
case, this environment variable contains two directory
lists separated by a semicolon.
If ld is called with any number of occurrences of -L, as
ld ... -Lpath1 ... -Lpathn ...
then the search path ordering is:
dirlist1 path1 ... pathn dirlist2 LIBPATH
When the list of directories does not contain a semi-
colon, the list is interpreted as dirlist2.
The LD_LIBRARY_PATH environment variable also affects
the runtime linkers search for dynamic dependencies.
This environment variable can be specified with a _32 or
_64 suffix. This makes the environment variable
specific, respectively, to 32-bit or 64-bit processes
and overrides any non-suffixed version of the environ-
ment variable that is in effect.
OKay good to know .. but ignore that for now.
A default set of options to ld. LD_OPTIONS is inter-
preted by ld just as though its value had been placed on
the command line, immediately following the name used to
invoke ld, as in:
ld $LD_OPTIONS ... other-arguments ...
OKay you need that.
An alternative mechanism for specifying a runpath to the
link-editor. See the -R option. If both LD_RUN_PATH and
the -R option are specified, -R supersedes.
Nice to know also.
So go back and recompile and set LD_RUN_PATH=/some/path/to/lib as well
as set LD_OPTIONS='-R/some/path/to/lib -L/some/path/to/lib ' and when
the link stage hits your output ELF files will have both a RUNPATH and
a RPATH set. If you're using gcc you may also specify the option
-Wl,-rpath=/some/path/to/lib and you will get that passed to the linker.
More information about the openssl-users