Arch Linux

rek

Member

Registered: 2023-03-02

Posts: 31

what is the proper way to set up LD_LIBRARY_PATH

i want to know a best practices default value for the LD_LIBRARY_PATH variable, and how/where it should best be set for most cases.

for example, should it point to one directory or a list of directories? if so, which? should it be set in just .bashrc or some other more central way?

I'm trying to use various cuda based software and frequently get errors relating to LD_LIBRARY_PATH

I use miniconda3 and it hijacks that variable away from libraries located in /opt, changing the value somehow outside of the scope of .bashrc and referring to its own directory.
i want to wean myself off of conda if possible and deal with venvs the old 'source activate' way that doesn't cause more problems than it solves.

, but in the meantime I am looking for a standard best practices way to set and forget the LD_LIBRARY_PATH

Last edited by rek (2024-12-11 22:18:09)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,204

Re: what is the proper way to set up LD_LIBRARY_PATH

It should not be set at all. It's an emergency override for when you (or tools that think they do) know better. And if there is such a case you set it on demand for the cases you know you need them for.

The fact that miniconda hijacks the variable is a known issue and instead of trying to fix LD_LIBRARY_PATH you should either stop using conda entirely, or at the very least remove conda init from your shell rc/shell profile files and only run conda init when you actually mean to work with a conda project on demand and don't use it for general shell initialization.

The "proper" way to set different library lookup paths that should be valid more or less globally are drop in files in /etc/ld.so.conf.d

Last edited by V1del (2024-12-12 00:24:40)

rek

Member

Registered: 2023-03-02

Posts: 31

Re: what is the proper way to set up LD_LIBRARY_PATH

It should not be set at all. It's an emergency override for when you (or tools that think they do) know better. And if there is such a case you set it on demand for the cases you know you need them for.

The fact that miniconda hijacks the variable is a known issue and instead of trying to fix LD_LIBRARY_PATH you should either stop using conda entirely, or at the very least remove conda init from your shell rc/shell profile files and only run conda init when you actually mean to work with a conda project on demand and don't use it for general shell initialization.

i have uninstalled miniconda3 and now git doesn't even work anymore because there's some linkers with libcurl that are still set to the miniconda lib location. it's fun while its working but conda can really wreak havoc with links.

example:

./setup.sh
Skipping git operations.
Arch Linux or Arch base detected.
pacman: /home/username/miniconda3/lib/libcurl.so.4: no version information available (required by /usr/lib/libalpm.so.15)

i had no idea that miniconda burrowed its way to pacman. i went into pacman conf and saw not even one word of miniconda or conda in there, meaning that there's some other place where there's a dead link left over from conda which makes certain libraries unfindable now, even after uninstalling and reinstalling them.  I'm still noobish about where to look for those kind of solutions but i feel like conda goes a bit too far when the entire theory of virtual environments is to keep unwanted system wide configurations from happening.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,204

Re: what is the proper way to set up LD_LIBRARY_PATH

reboot/open a new shell and/or check your .bashrc/.bash_profile and/or /etc/profile for whether any remnants of this is still remaining. It doesn't burrow itself into pacman but it reconfigures your shell environment.

In doubt grep some common offenders e.g.

grep -R conda /etc/profile* ~/.bash* ~/.profile

or so, adjust relevantly if you use a different shell. you need to get rid of invocations of conda init and similar.

Last edited by V1del (2024-12-12 00:40:51)