LD_LIBRARY_PATH settings in /etc/profile lost

Bug #367814 reported by microbug on 2009-04-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Before upgrading from Intrepid to Jaunty, I set LD_LIBRARY_PATH in /etc/profile as follow

export LD_LIBRARY_PATH=some_path

And it worked fine on Intrepid. After upgrading to Jaunty, this setting takes no effect any more. If I open a terminal and type in


it will show a blank path. But if I add the following statement to /etc/profile

export TEST_PATH=some_path

then the TEST_PATH variable will be correctly set. So it seems that the LD_LIBRARY_PATH setting in /etc/profile is in fact read and executed by the system, but the LD_LIBRARY_PATH variable is unset somewhere else later. Besides, I also tried to add the LD_LIBRARY_PATH setting directly into /etc/gdm/Xsession. And after logging in, I still got a blank value of LD_LIBRARY_PATH.

teju (teju) wrote :

Hi microbug,
   Can you try putting this line 'export LD_LIBRARY_PATH=some_path' into the file /etc/bash.bashrc file and then checking whether still you get a blank for '$LD_LIBRARY_PATH' or not?

Seems to be a bash related issue. Hence marking it as 'bash'...

microbug (dengbl) wrote :

Hi teju,

I tried what you suggested and it printed out the value of LD_LIBRARY_PATH correctly. Unfortunately, this does not help to solve my problem. I need to use the eclipse IDE to debug some program. Setting LD_LIBRARY_PATH in /etc/bash.bashrc will only affect the variable within a bash terminal. If I launch eclipse from a desktop launcher, the LD_LIBRARY_PATH seen by eclipse is still blank. That's why I tried to set it in /etc/profile. And up till now I still cannot find a way to set this value correctly for a program executed from a desktop launcher.

ceg (ceg) wrote :

PAM may be more appropriate then shell rc files (etc/pam.d)

ceg (ceg) wrote :

See "man pam_env", /etc/security/pam_env.conf and /etc/environment for a solution to your problem.

If gdm used to source /etc/profile, and now stopped this misbehaviour, that is good.

ceg (ceg) wrote :

Hope the solution above helps to understand this bug as "invalid"?
Shell config files are supposed to work only for (even specific) shells, pam is more a global method.

Changed in ubuntu:
status: New → Invalid
Hendy Irawan (ceefour) wrote :

The real bug in this case is bug #366728.

It is specific to LD_LIBRARY_PATH, and not other environment variables.

For example, if you set some environment variable in your /etc/profile or ~/.profile, most likely the software will detect it.

However, LD_LIBRARY_PATH even if set in /etc/environment (which is the proper place to put system-wide environment variables), is not working. Hence even "/etc/environment for a solution to your problem" proposed by @ceg does not work.

Bug #366728 also proposes a workaround by ~robinmillis :

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

ceg (ceg) wrote :

Thanks for the pointer!

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

Other bug subscribers