This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc cvs breaks JDK Mozilla plugin
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: glibc cvs breaks JDK Mozilla plugin
- From: "Kevin B. Hendricks" <khendricks at ivey dot uwo dot ca>
- Date: Sun, 29 Oct 2000 07:45:25 -0500
- Cc: drepper at cygnus dot com, howarth at fuse dot net, libc-alpha at sourceware dot cygnus dot com
- References: <v03110703b6210940dd48@[64.229.15.119]>(khendricks@ivey.uwo.ca) Jack Howarth's message of "Sat, 28 Oct 200017:33:46 -0400" <39FB463A.E29438DC@fuse.net><v03110703b6210940dd48@[64.229.15.119]>
Hi,
> As Jack said, the problem is that something else is resetting the search
> path before libjvm.so is actually even searched for.
>
>I don't see any evidence of something "resetting" the search path.
That was not meant to be a "technical" diagnosis. The log shows the
classic subdirectory being searched for libpthread.so just before that, it
shows the correct LD_LIBRARY_PATH set to look for the libjvm.so shared lib,
and then it does not show any attempts to search that path or to try to
load anything from that path, thus my "something is reseting that path".
This does not mean aliens came down and did something bad ;-)
It means the jdk plugin code seems to be doing the right thing here and
that the problem is with the glibc cvs code and not the jdk or mozilla code
(which was still being debated by Ulrich as a possible source for the
problem).
>Looking at Jack's LD_DEBUG log, and the code in elf/dl-load.c:open_path, it
>looks as if the directories in the LD_LIBRARY_PATH search path are all
>marked nonexistent, possibly because __xstat64 isn't functioning properly.
Okay, have there been any recent changes to that code from Oct 23rd to
today's cvs that might hint at the problem?
Thanks,
Kevin