Thomas Fitzsimmons writes:
> Andrew Haley wrote:
> > Thomas Fitzsimmons writes:
> > >
> > > 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.
> >
> > Can we not have a version of this that works correctly with
> > already-installed systems?
>
> We could, but that would need GIJ_EXECUTABLE, which Bryce didn't
> like. FWIW, to avoid confusion, and problems like the one you've
> encountered, I prefer hard-coding executables that I intend to
> exec. But doing so would compromise Bryce's vision of a
> relocatable libgcj.
Maybe, but you simply cannot assume that argv[0] contains the path to
the current executable. It's a fragile technique that runs the risk
of horrors like this one. /proc/self/exe works on Linux.