This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ Build Problem (CVS)
- To: Brad Cox <bcox at virtualschool dot edu>
- Subject: Re: GCJ Build Problem (CVS)
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Date: Mon, 12 Nov 2001 13:27:05 +1300
- Cc: Jeff Sturm <jsturm at one-point dot com>, java at gcc dot gnu dot org
- References: <8AE3AB2C-D63A-11D5-83FA-0005022D9F0A@virtualschool.edu>
Brad Cox wrote:
> [bcox@linux bcox]$ locate libgcj.so
> /usr/lib/libgcj.so.1
> /usr/lib/libgcj.so.1.0.0
> /usr/lib/libgcj.so
> /usr/local/lib/libgcj.so.2
> /usr/local/lib/libgcj.so.2.0.0
> /usr/local/lib/libgcj.so
> export LD_LIBRARY_PATH="$(GCC)/lib:$(LD_LIBRARY_PATH)" && a.out
>
> IT WORKED!
Yeah, that makes sense. Note that the new libgcj won't conflict with the
Redhat one in /usr/lib, since they have different "soname" (major
version number), but the one in /usr/local/lib will since it has the
same name so the dynamic linker can't tell the difference. "ldd a.out"
will always tell you exactly what library the dynamic linker is going to
use for a given binary.
regards
Bryce.