Ubuntu

LD_LIBRARY_PATH settings in /etc/profile lost

Bug #367814 reported by microbug
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu
Invalid
Undecided
Unassigned

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

echo $LD_LIBRARY_PATH

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.

Revision history for this message
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'...

Revision history for this message
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.

Revision history for this message
ceg (ceg) wrote :

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

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
ceg (ceg) wrote :

Thanks for the pointer!

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

Other bug subscribers

Remote bug watches

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