Bug 144935 - LD_ASSUME_KERNEL breaks library search path
Summary: LD_ASSUME_KERNEL breaks library search path
Status: RESOLVED INVALID
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Preview 4
Hardware: Other Other
: P5 - None : Minor
Target Milestone: ---
Assignee: Thorsten Kukuk
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-23 19:40 UTC by Jeff Stedfast
Modified: 2006-07-24 13:37 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Stedfast 2006-01-23 19:40:12 UTC 
I set LD_ASSUME_KERNEL=2.2.5 (and have for years) to work around various thread issues when gdbing multithreaded applications (as I'm sure many developers do).

With a recent update after installing preview4 (so not with the rpm's from preview4, but post preview4), setting this environment yields the following fun in my bash shell:

[fejj@linux ~]$ ls
ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
[fejj@linux ~]$ emacs
emacs: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory
[fejj@linux ~]$ vi
vi: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
Comment 1 Dr. Werner Fink 2006-01-24 10:49:28 UTC 
The thread system is NPTL. As new glibc does not support anymore the
old thread system you have to change your programs and environment.
If you do not like this you may talk to the glibc people.
Comment 2 Jeff Stedfast 2006-01-24 16:16:06 UTC 
you could at least make it so that it doesn't completely break the environment when that variable is set.
Comment 3 Dr. Werner Fink 2006-01-24 16:46:50 UTC 
Reopen
Comment 4 Thorsten Kukuk 2006-01-24 16:51:47 UTC 
(In reply to comment #2)
> you could at least make it so that it doesn't completely break the environment
> when that variable is set.

It does not break the environment, the environment is broken.
glibc+NPTL needs at least kernel 2.6.4, if you tell glibc that it is only allowed to use 2.2.5, there is nothing glibc can do.
Comment 5 Michael Gross 2006-07-24 13:37:02 UTC 
I might add that because of this many install scripts (for example Maple) do not work any longer as those scripts tend to set this variable. We might at least give the user some clue about this, maby in the release notes or the online help.