Sujet : Re: Python (was Re: I did not inhale)
De : lew.pitcher (at) *nospam* digitalfreehold.ca (Lew Pitcher)
Groupes : comp.unix.shell comp.unix.programmer comp.lang.miscDate : 22. Aug 2024, 15:58:54
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <va7g6u$eggg$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
User-Agent : Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)
Please forgive my interruption, but something in Muttley's comment needs
some clarification....
On Thu, 22 Aug 2024 15:11:33 +0200, D wrote:
On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
[snip]
For a properly designed language a container shouldn't be required. Using
a container to prevent library hell is like seeing a mess on your floor but
instead of clearing the mess you sweep it into seperate piles depending on
the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH
1) The ability to alter the loader's library search path isn't a C/C++ feature,
but, instead, is a feature of the loader, and is applicable to /any/ binary
that uses "shared objects" ("DLL"s to those who came from a Windows environment).
2) LD_LIBRARY_PATH is not "the" Unix environment variable that alters the loader's
library search path. Rather, it is /one flavour/ of such an environment variable.
Depending on the Unix system, the environment variable can be called:
LD_LIBRARY_PATH, or
LIBPATH, or
SHLIB_PATH, and
there may be other names that I don't know of.
to use particular shared object files
but doing something similar with Python AFAIK is a hell of
a task.
>
Thank you! You make me feel less of an outsider and old timer! ;)
-- Lew Pitcher"In Skills We Trust"