[Top][All Lists]
[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?"
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Fwd: Re: ldconfig troubles,
Kelledin <=