|
From: Harlan S. <ha...@pf...> - 2024-02-21 05:27:20
|
On 2/20/2024 8:38 PM, Sternberg, Michael G. via Modules-interest wrote:
> 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.
Thanks!
And:
- I'd greatly prefer to avoid LD_LIBRARY_PATH, as relying on this has
always resulted in intricate debugging problems and drama. It also
requires education and significant attention on the part of the
sysadmin/releng/build teams.
- Is there a non-clunky solution to the problem of needing to compile
N instances of perl for each of the N versions of openssl that are
available?
My first point above is still a major concern for me.
The 2nd point is independent of the first point. Doing N instances of
perl+openssl may be what has to happen. And I'm wondering what other
toolchains will need to have their own collections:
- perl-$PERLVER--noopenssl
- perl-$PERLVER--openssl-$OPENSSLVER
H
--
> 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".
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|
