Re: Patch: RFA: set LD_LIBRARY_PATH

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

On Mon, 2005-09-05 at 17:19 +0100, Andrew Haley wrote:
> Thomas Fitzsimmons writes:
>  > On Mon, 2005-09-05 at 14:05 +0100, Andrew Haley wrote:
>  > > Thomas Fitzsimmons writes:
>  > >  > 
>  > >  > Sun's JRE includes $JAVA_HOME/lib/<arch> in its LD_LIBRARY_PATH so that
>  > >  > users don't need to specify LD_LIBRARY_PATH manually.  This patch makes
>  > >  > libgcj do the same when the --with-java-home configure option is
>  > >  > specified.
>  > >  > 
>  > >  > OK for mainline?
>  > > 
>  > > In what circumstances is this necessary?
>  > 
>  > The specific use case I'm trying to support with this patch is running
>  > Java applications that link against libjawt.so.  Sun installs this
>  > library in $JAVA_HOME/lib/<arch>.  See:
>  > 
>  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
>  > 
>  > >   Should not the appropriate
>  > > libraries be installed somewhere where LD_LIBRARY_PATH isn't needed?
>  > 
>  > We tried that before, see:
>  > 
>  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20790
>  > 
>  > When our JAWT implementation was installed in GCC's library prefix it
>  > was overriding Sun's libjawt.so when compiling JAWT-using applications
>  > against proprietary VMs.
> 
> OK, so we renamed the lib to libgcjawt.so.  Why can't libgcjawt.so be
> installed in the common place for shared libraries, /usr/lib?  Its
> name prevents it from colliding with other libraries.
> 
>  > > What if a user specifically sets LD_LIBRARY_PATH in order to _avoid_
>  > > $JAVA_HOME/lib/<arch>?
>  > 
>  > They can't avoid it.  But I don't know why they would want to.  The idea
>  > here is that LD_LIBRARY_PATH only includes $JAVA_HOME/lib/<arch> when --
>  > with-java-home is specified.
> 
> I understand that, but most of our users don't build their own libgcj.
> 
> Making libgcj mess with LD_LIBRARY_PATH at runtime is a pretty evil
> hack.  If users are going to link their own programs with -ljawt, then
> they're going to be setting LD_LIBRARY_PATH anyway.
> 
> I guess the problem is I still don't understand the scenario you have
> in mind.

The scenario is simply how people build and run JAWT applications with
Sun's SDK.  The attached Makefile sums it up.  Setting JAVA_HOME then
running "make && make run" works with Sun's SDK.  I'm trying to support
the same scenario in java-gcj-compat.

Note that LD_LIBRARY_PATH only points to the current directory where the
libDemoJAWT.so JNI library resides.  There's no need for the user to
point LD_LIBRARY_PATH at libjawt.so; even though it's in a non-standard
location ($JAVA_HOME/jre/lib/i386) it is searched for JNI library
dependencies.

If we made our JAWT library binary compatible, i.e. called libjawt.so
with SONAME "libjawt.so" and installed it in a standard library location
it would override Sun's libjawt.so -- obviously not what the user wants.
So we need to hide it in an alternatives-managed non-standard library
location instead.

The other issue this solves is library versioning.  Sun's libjawt.so is
unversioned.  Lately we've been supporting installing multiple major
versions of libgcj in parallel.  By hiding our unversioned compatibility
libjawt.so in a non-standard prefix we can still support such multi-
library configurations by managing libjawt.so via alternatives.  If we
installed libjawt.so directly in /usr/lib there could be only one
version installed on the system.

Tom

all: DemoJAWT.h DemoJAWT.class libDemoJAWT.so

%.class: %.java
	$$JAVA_HOME/bin/javac $<

%.h: %.class
	$$JAVA_HOME/bin/javah $(basename $< .class)

libDemoJAWT.so: DemoJAWT.c
	gcc -g -O0 -Wall -I. -I$$JAVA_HOME/include -I$$JAVA_HOME/include/linux -I/usr/X11R6/include -shared -o $@ DemoJAWT.c -L$$JAVA_HOME/jre/lib/i386 -ljawt -L/usr/X11R6/lib -lX11

run:
	LD_LIBRARY_PATH=. $$JAVA_HOME/bin/java DemoJAWT

clean:
	rm -f DemoJAWT.h DemoJAWT.class DemoJAWT\$$1.class libDemoJAWT.so