Re: Patch: install libgtkpeer.so and libjawt.so in versioned library directory

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

Hi,

Andrew Haley wrote:
> Thomas Fitzsimmons writes:
>
>  > +
>  > +  // Check if LD_LIBRARY_PATH is already prefixed with
>  > +  // GCJ_VERSIONED_LIBDIR.  If not, export LD_LIBRARY_PATH prefixed
>  > +  // with GCJ_VERSIONED_LIBDIR and re-spawn gij.
>  > +  char *libpath = getenv (LTDL_SHLIBPATH_VAR);
>  > +  char *newpath = _Jv_PrependVersionedLibdir (libpath);
>  > +
>  > +  if (! libpath || strcmp (libpath, newpath))
>  > +    {
>  > +      setenv (LTDL_SHLIBPATH_VAR, newpath, 1);
>  > +      JvFree (newpath);
>  > +
>  > +      int error_code = execv (GIJ_EXECUTABLE, (char* const*) argv);
>
> But, as discussed with Bryce, the version in svn is
>
>      int error_code = execvp (argv[0], (char* const*) argv);
>
> This can break java-1.4.2-gcj-compat.
>
> /usr/bin/java prefixes the LD_LIBRARY_PATH with the gij install dir.
> Then, /usr/bin/java does an execv of PREFIX/gij, but it leaves argv[0]
> pointing to /usr/bin/java rather than PREFIX/gij.

Yes, /usr/bin/java must now be symlinked to gij, rather than being a binary 
wrapper itself.  The idea of this patch was to merge the functionality from 
java-gcj-compat's java.c into gij itself, so that we could get rid of java.c in 
favour of a symlink.

> So, when you call execvp(), the /usr/bin/java wrapper is re-executed,
> not gij.  This in turn, re-executes gij, ad nauseam.
>
> So, to make this clear:
>
> /usr/bin/java prefixes LD_LIBRARY_PATH and execs gij
> gij prefixes LD_LIBRARY_PATH and execs /usr/bin/java
> /usr/bin/java prefixes LD_LIBRARY_PATH and execs gij
> gij prefixes LD_LIBRARY_PATH and execs /usr/bin/java
> ...

This only happens because each tool execs the other.  This won't happen when 
java symlinks to gij.

Tom