This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/5] gcc: configure and Makefile changes needed by jit
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, <jit at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 15 Oct 2014 18:48:17 +0000
- Subject: Re: [PATCH 2/5] gcc: configure and Makefile changes needed by jit
- Authentication-results: sourceware.org; auth=none
- References: <1413222308-25753-1-git-send-email-dmalcolm at redhat dot com> <1413222308-25753-3-git-send-email-dmalcolm at redhat dot com> <543EB0AA dot 5030903 at redhat dot com> <1413397540 dot 9513 dot 125 dot camel at surprise>
On Wed, 15 Oct 2014, David Malcolm wrote:
> As for the "bindir" in site.exp, Joseph asked me when the library
> invokes a driver to convert from .s to .so to:
>
> On Tue, 2014-09-23 at 23:27 +0000, Joseph S. Myers wrote:
> > * use the $(target_noncanonical)-gcc-$(version) name for the
> > driver rather than plain "gcc", to maximise the chance that it
> > is actually the same compiler the JIT library was built for (I
> > realise you may not actually depend on it being the same
> > compiler, but that does seem best; in principle in future it
> > should be possible to load multiple copies of the JIT library
> > to JIT for different targets, so that code for an offload
> > accelerator can go through the JIT).
> ( https://gcc.gnu.org/ml/jit/2014-q3/msg00033.html )
>
> This full name is used when *installing* the driver, but doesn't exist
> within the build directory.
> Hence when running the library, the installation bindir needs to be in
> the PATH. In particular, (in
> https://gcc.gnu.org/ml/jit/2014-q4/msg00005.html ) when running the jit
> testsuite we rely on the driver having been installed, and in jit.exp we
> need to temporarily prepend the installation bindir onto the front of
> PATH when running test programs linked against libgccjit.so. Hence we
> need to know what bindir is from expect, hence we add it to site.exp.
Even if the driver's been installed, it might not be in the configured
bindir but in some other DESTDIR.
Really, the need for an installed driver for testing should be avoided.
The ideal way to do that is for "make check" to install to a staging
directory within the build directory (generally, the DejaGnu approach of
passing lots of -B etc. options to tell bits of the toolchain how to find
each other, with lots of relevant logic hardcoded inside DejaGnu itself,
is problematic and the staging directory approach would be better,
although it has various other complications given that GCC needs to find
separately built / installed pieces such as binutils and runtime
libraries). Of course that's a much more general issue - I suppose
someone with an installation in a DESTDIR can still test as-is by
specifying a different value of bindir on the "make" command line that
builds site.exp?
--
Joseph S. Myers
joseph@codesourcery.com