bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: ldconfig troubles


From: Kelledin
Subject: Fwd: Re: ldconfig troubles
Date: Sun, 1 Sep 2002 13:12:33 -0500
User-agent: KMail/1.4.2

A comrade and I recently discovered this problem in the process 
of compiling Sun J2SDK 1.4.0, and we're pretty certain it's down 
to an ldconfig bug.

Basically, j2sdk keeps its shared libraries in 
$JAVA_HOME/jre/lib/i386 and a few subdirectories therein.  j2sdk 
binaries such as java_vm are linked against these libraries.

The problem occurs when we add the relevant library paths to 
/etc/ld.so.conf and run ldconfig -v.  The library paths are 
added, and *some* of the libraries get pulled in properly at 
run-time--but not all.  In particular, the run-time linker can't 
locate $JAVA_HOME/jre/lib/i386/libverify.so, even though it can 
locate most other libs in the same directory.

Change the directory from i386 to blah, and it works.  Use 
LD_LIBRARY_PATH (instead of /etc/ld.so.conf) to store the 
directory, and it works.  Change it to an architecture that 
matches the `uname -m` exactly, like i686, and it works (near as 
we can tell--i686 is all I have to test it on atm).

The problem occurs whether you use the precompiled j2sdk-1.4.0 or 
the compiled-from-scratch j2sdk-1.4.0.  Same problem has been 
reported with j2sdk-1.3.1 in ages past.  Precompiled j2sdk 
probably works with older glibc's (like 2.1.3), but I haven't 
the time to test it myself.  Probably the reason we never hit 
this bug with anything else is because j2sdk is the only thing 
we use that installs a library directory with an 
architecture-specific name.

----------  Forwarded Message  ----------

Subject: Re: j2sdk *still* sucks...
Date: Sun, 01 Sep 2002 12:47:41 -0500
From: Tushar Teredesai <address@hidden>
To: Kelledin <address@hidden>

Kelledin wrote:
>On Sunday 01 September 2002 12:23 am, you wrote:
>>So I am guessing that instead of using a wrapper script just
>>renaming the directories (and creating i386 -> i686 sym link
>>for the renamed dirs for safety) should solve the problem?
>
>Hopefully, yes.  Renaming the directories to `uname -m` should
>work fine...strange that this would fix it.  Just as a test,
>what happens if you rename "i386" to "i486" instead?
>
>Now it sounds like the glibc runtime linker (ldconfig
> especially) has a bug determining which architectures are
> compatible with others--it *should* figure out that
> i386-specific libs can be used when corresponding i686 libs
> don't exist, but apparently it's not doing that reliably.  Do
> you think we should post the gist of this sordid affair to the
> glibc mailing lists?

Yeah, I think it is a bug with ldconfig and should be posted to
 the glibc mailing list.

Based on the reference link I sent you, instead of adding
</opt/j2sdk/j2sdk-1.4/jre/lib/i386> to /etc/ld.so.conf, I added
</opt/j2sdk/j2sdk-1.4/jre/lib> since according to the link,
 ldconfig automatically adds platform specific subdirectories.

ldconfig -v verifies that inded both
 </opt/j2sdk/j2sdk-1.4/jre/lib/i386> and
 </opt/j2sdk/j2sdk-1.4/jre/lib> are added to the ld.so.cache.

Running java_vm after that still gives me "unable to load shared
 lib" error. Renaming i386 to i686 worked.

(BTW, /opt/j2sdk/j2sdk-1.4/jre/lib/i386/client was already in
/etc/ld.so.conf when I ran the experiments.)

--Tushar.

-------------------------------------------------------

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]