This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: wrong libgcc_s.so picked up in testsuite
- From: Tom Tromey <tromey at redhat dot com>
- To: Michael Ritzert <ritzert at t-online dot de>
- Cc: java at gcc dot gnu dot org
- Date: 27 Feb 2003 20:01:47 -0700
- Subject: Re: wrong libgcc_s.so picked up in testsuite
- References: <200302271737.26472.ritzert@t-online.de>
- Reply-to: tromey at redhat dot com
>>>>> "Michael" == Michael Ritzert <ritzert at t-online dot de> writes:
Michael> I see hundreds of testsuite failure for libjava because the
Michael> wrong version of libgcc_s.so is picked up by the linker:
Michael> I guess it's because I have
Michael> % echo $LD_LIBRARY_PATH
Michael> /opt/gcc-3.2.2/lib:
Michael> % echo $LD_RUN_PATH
Michael> /opt/gcc-3.2.2/lib:
Michael> It this configuration unsupported or is this a bug in the
Michael> testsuite?
I'm not sure.
I suppose it would make sense for the test suite to always use its own
LD_LIBRARY_PATH. But what if the user really needs to put a directory
there? For instance to run some program that the test suite needs?
It's interesting, though, because it looks like we do put our entries
at the start:
setenv LD_LIBRARY_PATH "$ld_library_path:$original_ld_library_path"
Is LD_RUN_PATH used first? That could cause the problem. We could
fix it by also setting this.
Could you investigate what we should do? One thing to try would be to
also set LD_RUN_PATH in the small proc near the end of libjava.exp (in
testsuite/lib).
Tom