LD_LIBRARY_PATH not loading from .profile nor /etc/environment

Same problem. Upgraded from 8.10 to 9.04 release. Not wubi installed.

~/.profile:
if [ -d "$HOME/lib" ] ; then
    export LIBRARY_PATH="$HOME/lib"
    export LD_LIBRARY_PATH="$HOME/lib"
fi

when logging in on tty1 LD_LIBRARY_PATH is set. In gnome it is not set.
Perhaps sourcing .profile in /etc/gdm/Xsession destroys it. Its the only place I could find that the varible is set during gdm login.

Also tried to create a fresh user account, add the above lines in ~/.profile, and log in in gdm. Same error still.

Is it related to this?:
http://www.linuxquestions.org/questions/linux-general-1/exporting-ldlibrarypath-problem-509967/

Found a workaround (or perhaps solution):
Move the variable setting to ~./.bashrc:

~/.profile:
if [ -d "$HOME/lib" ] ; then
    export LIBRARY_PATH="$HOME/lib"
fi

~/.bashrc:
if [ -d "$HOME/lib" ] ; then
    export LD_LIBRARY_PATH="$HOME/lib"
fi

sperlis said that LD_LIBRARY_PATH may be deleted for security reasons in certain situations. Is this the case here?

Declaring variables in ~/.bashrc is less efficient according to https://help.ubuntu.com/community/EnvironmentVariables:

"However, performance-wise this may not be the best thing to do since it will cause values to be unnecessarily set many times".

If LD_LIBRARY_PATH is blocked for security reasons it is not a bug. There should however be more information on this.

Thank you Zed for your support,

I tried to put it on .bashrc and it works if I open a bash terminal, but I cannot set it as a gnome global variable (.profile).
Now if I open a terminal and I tape: source .profile , the LD_LIBRARY_PATH is set, but the bug remains.

Quote>> LD_LIBRARY_PATH may be deleted for security reasons in certain situations. Is this the case here?
I don't think, because:
   1) it's independent of LD_LIBRARY_PATH address.
   2) this same example works perfectly on Ubuntu 7.04 - 7.10 - 8.04 - 8.10.

Thank you another time.

There is no way to set LD_LIBRARY_PATH as global GNOME variable,
So please fix it,
Thank you very much

I have another system that has the same setup, except it was installed with Wubi to 8.10, and then upgraded to 9.04. It is also 64 bit. I have the same problem with this system.

I think this issue is important, because any programs installed in user space, that uses shared libraries also installed in user space, will not run from a gnome launcher or Alt-f2.

I prefer not to mix the binaries maintained by the package manager with home brew apps and libs, and I prefer dynamic linking to static for my apps.

This problem still actual in ubuntu 9.10 karmic.
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
don't work in my ~/.profile.

I have the same problem....

And because of the introduction of the new gdm my session also doesn't source my "~/.xsessionrc" file anymore.
That's where I used to set all my session-wide environment variables previously.

Something that one could potentially do is add some userspace directory like ~/lib to /etc/ld.so.conf.d/ and then put symlinks to your shared libs into ~/lib. The library database has to be updated with sudo ldconfig each time a new lib appears in your folder, though. I don't like this approach very much and would much rather use .profile or LD_LIBRARY_PATH again.

The same happens in kubuntu (KDM). ssh sessions to the server will set the LD_LIBRARY_PATH (set in .cshrc here). When using the server over XDMCP will not set LD_LIBRARY_PATH. As a workaround, I added the path to konsole
(Settings -> Edit Current Profile -> Environment)

There is something very mysterious about LD_LIBRARY_PATH. It most certainly appears to be unset during startup. I've tried all the usual places /etc/profile and so on. I can set it in ~/.profile - however that's only effective when I for the bash shell. Processes started by the Windows Manager (eg QtCreator) do not execute ~/.profile (which is a bash-ism).

However it seems that while Ubuntu does respect LD_LIBRARY_PATH, it has another mechanism for locating dynamic libraries. If you run sudo ldconfig --verbose, it rebuilds a cache of shared libraries. So if you add a shared library (as I did) to /usr/local/lib, the correct medicine to make it available to run sudo ldconfig.

Of course this doesn't solve the inconvenience that LD_LIBRARY_PATH is somehow unset during startup. Perhaps a wizard on ldconfig can explain more about this.

In the file /etc/environment, I've added LD_LOVELY_PATH and LD_LIBRARY_PATH. LD_LOVELY_PATH survives startup. Somebody is removing LD_LIBRARY_PATH.

508 /home/rmills> cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LD_LOVELY_PATH="/usr/local/lib"
LD_LIBRARY_PATH="/usr/local/lib"
509 /home/rmills>

I had another couple of thoughts about this:
1) The Mac uses a 'magic' file to set the user's environment ~/.MacOSX/environment.plist
2) Windows uses the registry to set the user's environment

This feels correct to me. Bash (and the other shells) should have nothing to do with setting global (or user-wide) environment strings. Sure, the shells can change the environment - however the initial environment should be set elsewhere and I think that's about what /etc/environment does.

However somebody's modifying LD_LIBRARY_PATH between reading the file /etc/environment and user processes being started. Or maybe the parser for /etc/environment simply ignores LD_LIBRARY_PATH in a well-intended conspiracy with ldconfig.

Thanks ~robinmills for the workaround, I'll try it.

A similar (but unfortunately already marked as Invalid) issue is bug #367814.

As noted in https://help.ubuntu.com/community/EnvironmentVariables it's legal to use .profile, /etc/profile, or /etc/environment to set LD_LIBRARY_PATH.

But it's not working hence the bug is real.

It seems the proper way to "add to LD_LIBRARY_PATH" is not by using that env anymore, but by using ldconfig and /etc/ld.so.conf.d/*.conf files.

1. Add the ld.so configuration file :

echo "/opt/qt-mobility-src-1.0.0-tp2/install/lib" | sudo tee /etc/ld.so.conf.d/qt-mobility.conf

2. Update the cache

sudo ldconfig -v

Now the libraries are in your ld library path.

No messing with /etc/environment. And if you later decide to "uninstall" the libraries, just remove the conf file and run sudo ldconfig again. Cleaner solution for me.

I just wonder if this is also portable to other distros beside Ubuntu? (since LD_LIBRARY_PATH supposedly works on all Linux distros)

See http://linux.derkeiler.com/Mailing-Lists/Ubuntu/2008-02/msg02742.html for rationale.

"AFAIK LD_LIBRARY_PATH is unset in ubuntu, since the libraries are all
where they should be:)"

Digging around a bit I wonder if this is the issue:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/380360

So when you login, .profile is sourced. Then everything is parented to ssh-agent (I assume to inherit the environment variables that it sets) but as that is setuid, LD_LIBRARY_PATH is reset for security reasons.

However the usecase for wanting a per-user (i.e. not system wide) local prefix for development libraries is pretty valid. I don't want other users on the machine to be picking up my libraries when they run stuff, but I do want the setting to be session wide so it is picked up by applications I load from the command line.

I've just tested the workaround listed in in https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/380360 and it works for me.

To do it:

echo STARTUP=\"/usr/bin/env LD_LIBRARY_PATH=\${LD_LIBRARY_PATH} \${STARTUP}\" | sudo tee /etc/X11/Xsession.d/90preserve_ld_library_path

then restart your machine.

@Joe Kilner: This is not a workaround, since it requires root rights (sudo).

As far as I am concerned this bug is still wide open.

@Joe Kilner: that workaround does indeed work. Should be simple to fix this bug by adding that script to the default installation.

After 25 years of relying on LD_LIBRARY_PATH sourced from .profile I am quite surprised that this is bust. I have spent years trying to get people to use .bashrc, .profile etc. properly and it is frustrating watching people waste time on this topic and craft alternative solutions.

I think it is the same problem as https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/380360.

I noticed another workaround though:

ssh-agent is already initialised in /etc/gdm/Xsession. Empirically, t seems /etc/gdm/Xsession is initialised before .profile whereas /etc/X11/Xsession.options is initialised after .profile.

As ssh-agent needs to be initialised only once, simply disabling ssh-agent in /etc/X11/Xsession.options stops LD_LIBRARY_PATH from being set to null after .profile has been sourced. This can be done by changing use-ssh-agent to no-use-ssh-agent in /etc/X11/Xsession.options. This still requires root but is simpler...

Happy to confirm that the workaround from comment #21 is working for Ubuntu 10.04.

It would be good to know whether LD_LIBRARY_PATH is ignored in $HOME/.profile, /etc/profile, and /etc/environment since Ubuntu 9.04 a) with intention or b) by accident.
In case of a), which intention? https://help.ubuntu.com/community/EnvironmentVariables lacks an explanation.
In case of b), it is a bug that I would consider serious.

Confirmed on 10.04
We are using gridengine on lucid nodes, when submitting jobs using qsub all environment variables are imported correctly from /etc/profile except LD_LIBRARY_PATH, this variable is not present. VERY annoying bug!

Confirmed on 10.10

$uname -a
Linux hostname 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux

Same bug for me. I may define LD_LIBRARY_PATH from .bashrc or .zshrc, it will be OK, but only from a console, and won't be if I run an application from a *.desktop file as an example. So I wanted to define it in .profile, but what ever I do, it seems to be cleared unconditionally after interpretation of .profile. There is ldconfig, but unfortunately, this acts system wide, and I won't add a system wide entry for a library path which is relevant only for a single user.

This bug should be solved, and it seems it is still not solved.

Workaround proposed by James Spencer in message #21 works for me too (Ubuntu Maverick). Still feel sad that I must apply such a non-clean workaround.

Now there is no /etc/gdm/Xsession. So is it not appropriate to adopt the workaround as proposed in #21 ?

All of the work-arounds that have been listed everywhere up until this point have required root to change something in /etc/X11. Further, I don't particularly want to disable ssh-agent from loading.

Assuming Ubuntu uses a similar xsession configuration to Debian Jessie (which I imagine would be a safe bet), here is an alternative solution that can work - no root access required:

Just create a .xsession file with the contents:

#!/bin/bash

export $LD_LIBRARY_PATH=...whatever...

# Start our session manager of choice.
exec x-session-manager
### end

Make .xsession executable, and you should be in business. Read /etc/X11/Xsession.d/50x11-common_determine-startup, 90x11-common_ssh-agent and 99x11-common_start for a clear picture of why this works.

Requires allow-user-xsession to be set in /etc/X11/Xsession.options, but this is the default.

The cleanest workaround would be the comment #17 above (except maybe naming the file 89preserve_ld_library_path instead of 90preserve...).
The fix would be to add that code into the 90x11-common_ssh-agent script with an explanatory comment.