LD_LIBRARY_PATH not loading from .profile nor /etc/environment

Bug #366728 reported by lixo1
This bug affects 39 people
Affects Status Importance Assigned to Milestone
xorg (Debian)
xorg (Ubuntu)
Declined for Jaunty by Sebastien Bacher
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher

Bug Description

Hi everybody,

Today I installed Ubuntu 9.04 (wubi) and I tried to add a LD_LIBRARY_PATH to my .profile file, the command is:
export ROOTSYS=/usr/share/QtRoot/root

Now, when I login, I tape printenv on the bash and the LD_LIBRARY_PATH is not set.
This same 2 lines on .profile, have been working perfectly on the last 3 Ubuntu versions.

Thank you very much, and please someone fix it quickly.

Revision history for this message
Zed (scientist47-xyz) wrote :

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

if [ -d "$HOME/lib" ] ; then
    export LIBRARY_PATH="$HOME/lib"
    export LD_LIBRARY_PATH="$HOME/lib"

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.

Revision history for this message
Zed (scientist47-xyz) wrote :

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

Zed (scientist47-xyz)
Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Zed (scientist47-xyz) wrote :
Revision history for this message
Zed (scientist47-xyz) wrote :

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

if [ -d "$HOME/lib" ] ; then
    export LIBRARY_PATH="$HOME/lib"

if [ -d "$HOME/lib" ] ; then
    export LD_LIBRARY_PATH="$HOME/lib"

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.

Revision history for this message
lixo1 (lixo1) wrote :

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.

Revision history for this message
lixo1 (lixo1) wrote :

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

Revision history for this message
Zed (scientist47-xyz) wrote :

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.

Revision history for this message
SaNuke (sanuke) wrote :

This problem still actual in ubuntu 9.10 karmic.
don't work in my ~/.profile.

Revision history for this message
SiLeNcE (bastian-beischer) wrote :

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.

Revision history for this message
Alvin (alvind) wrote :

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)

Revision history for this message
robinmills (robinmills) wrote :

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.

Revision history for this message
robinmills (robinmills) wrote :

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
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.

Revision history for this message
Hendy Irawan (ceefour) wrote :

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

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

summary: - LD_LIBRARY_PATH not loads from .profile
+ LD_LIBRARY_PATH not loading from .profile nor /etc/environment
Revision history for this message
Hendy Irawan (ceefour) wrote :

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.

Revision history for this message
Hendy Irawan (ceefour) wrote :

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:)"

Revision history for this message
Joe Kilner (joekilner) wrote :

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


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.

Revision history for this message
Joe Kilner (joekilner) wrote :

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.

Revision history for this message
Foobar (ron-gamr7) wrote :

@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.

Revision history for this message
Captain Chaos (launchpad-chaos) wrote :

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

Revision history for this message
Oliver Dungey (oliver-dungey) wrote :

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.

Revision history for this message
James Spencer (james-s-spencer) wrote :

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...

Revision history for this message
Marcus Letzel (letzel-marcus) wrote :

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.

Revision history for this message
Philipp Lies (philipp-lies) wrote :

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!

Revision history for this message
Brent W. Barker (b-w-barker) wrote :

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

Timo Aaltonen (tjaalton)
affects: ubuntu → xorg (Ubuntu)
Changed in xorg (Ubuntu):
importance: Undecided → Medium
Changed in xorg (Debian):
status: Unknown → Incomplete
Revision history for this message
Hibou57 (Yannick Duchêne) (yannick-duchene) wrote :

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.

Revision history for this message
Hibou57 (Yannick Duchêne) (yannick-duchene) wrote :

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.

Revision history for this message
funicorn (funicorn) wrote :

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

Revision history for this message
Adam Bolte (boltronics) wrote :

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:


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.

Revision history for this message
noon (fabrice-bauzac) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.