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: David Malcolm <dmalcolm at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: jit at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 15 Oct 2014 17:29:28 -0400
- 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> <543EDE61 dot 6090801 at redhat dot com>
On Wed, 2014-10-15 at 14:51 -0600, Jeff Law wrote:
> On 10/15/14 12:25, David Malcolm wrote:
> > On Wed, 2014-10-15 at 11:36 -0600, Jeff Law wrote:
> >> On 10/13/14 11:45, David Malcolm wrote:
> >>> gcc/ChangeLog:
> >>> * configure.ac (gcc_version): Expose this value for use via
> >>> AC_SUBST, since the jit code needs it within the new file
> >>> libgccjit.pc.in.
> >>> (doc_build_sys): New variable, set to "sphinx" if
> >>> sphinx is installed, falling back to "texinfo" otherwise.
> >>> (gcc-driver-name.h): Generate a gcc-driver-name.h file containing
> >>> GCC_DRIVER_NAME for the benefit of jit/jit-playback.c.
> >>> * configure: Regenerate.
> >>> * Makefile.in (doc_build_sys): New.
> >>> (bindir): New.
> >>> (pkgconfigdir): New.
> >>> (installdirs): Add creation of $(DESTDIR)$(pkgconfigdir).
> >>> (site.exp): When constructing site.exp, add a line to set "bindir".
> >> Mostly OK. Though a couple questions.
> >>
> >> Why do we need pkgconfig and why do you need a bindir in site.exp?
> >
> > I chose to provide a libgccjit.pc file in the install, so that client
> > code has the option of compiling and linking against the library like
> > this:
> >
> > $ gcc jit-hello-world.c $(pkg-config libgccjit --cflags)
> > $ gcc jit-hello-world.o $(pkg-config libgccjit --libs)
> WIthout a general consensus to add pkg-config, I'd rather not go this
> direction. Right now I'd much rather see us adding the appropriate
> flags automatically.
How could we do that automatically? The reason I wanted to use
pkg-config here is not for us, it's for the users of the jit library,
e.g. GNU Octave, my "coconut" jit for CPython etc. I don't want to
require clients of this code to use the GNU autotools (for example, the
Python bindings don't).
How do *they* select the correct include paths and linker flags for
building against libgccjit? It's easy if the relevant files got put
into /usr/include and /usr/lib, but there could be multiple versions
installed in different prefixes for different development stacks.
pkg-config solves this by having the user set up PKG_CONFIG_PATH to pick
up the relevant .pc files for each library.
[well, it's also for *me* when I'm using the library, in that I've made
use of the pkg-config approach quite a bit since adding the support]
> > relying on pkg-config to automatically supply the relevant flags for the
> > correct paths (for those people who want to use pkg-config).
> But I think that is a completely independent discussion and if we go
> that direction we should make it pervasive in GCC and not just for the
> JIT bits.
I think that the jit is a special case here: I don't know of any other
shared libraries built from the gcc codebase that are intended to run on
the host, and are for use by 3rd-party libraries/binaries. (though to
be fair, the jit rather blurs the host/build line).
But if this is going to block acceptance of the branch I can drop it;
client code can always just manually specify the -I and -l/-L
accordingly.
> > 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.
> So if I'm reading all this correctly, what's being implied is that
> testing is done using the installed bits rather than the in-build-tree
> bits? We really need this to run without having been installed.
One approach here might be to do make a copy of the driver binary with
the final name within the *build* dir (e.g.
"x86_64-unknown-linux-gnu-gcc-5.0.0").
Another might be the "run the driver code in-process" approach I dabbled
with here:
https://gcc.gnu.org/ml/jit/2014-q3/msg00049.html
though that's some way from working, and is more invasive (no-one
replied to that email)