|
From: Sternberg, M. G. <ste...@an...> - 2024-02-21 04:52:54
|
You can certainly get by with a single perl binary by putting the specific version of openssl right under its nose, though a script wrapper:
----------------------------
#!/bin/sh
LD_LIBRARY_PATH=/path/to/openssl/lib${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"} \
exec /path/to/bin/perl \
${1+"$@"}
----------------------------
Place this script "earlier" in your PATH than your perl binary.
If you happen to control that perl binary yourself (as opposed to e.g. your system's package manager), you could also move it to, say, ../libexec/ and place the script in its stead. In that case, you could write "… exec $(dirname $0)/../libexec/perl …" to locate it.
With best regards,
--
Michael Sternberg, Ph.D.
Principal Scientific Computing Administrator
Center for Nanoscale Materials
Argonne National Laboratory
On Feb 20, 2024, at 20:56, Harlan Stenn <ha...@pf...> wrote:…There are some CPAN modules that work with, for example, OpenSSL. These
CPAN modules need the right/appropriate OpenSSL libraries at runtime.
CPAN modules apparently Do Not Want to be statically linked. I think
the best solution is to find a way to install CPAN modules that have
been statically linked to there appropriate (at build time) libraries.
I really don't want to use LD_LIBRARY_PATH to solve this problem,
because in an environment where modules is in use, one might be using
several different sets of tools, and the openssl being used by perl and
the perl modules might be different from the version of openssl that is
used by some other set of utilities that are needed for the current
overall operating environment.
I am trying Really Hard to not have to build a separate version of perl
(and the CPAN modules) for each version of OpenSSL.
I figure there are more "flavors" involved than just OpenSSL, so the
problem above will only get worse if I have to build an entire toolchain
suite for each "flavor".
|
