From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10152 invoked by alias); 15 Oct 2014 21:33:29 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 10132 invoked by uid 89); 15 Oct 2014 21:33:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Message-ID: <1413408568.9513.151.camel@surprise> Subject: Re: [PATCH 2/5] gcc: configure and Makefile changes needed by jit From: David Malcolm To: Jeff Law Cc: jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Date: Wed, 01 Jan 2014 00:00:00 -0000 In-Reply-To: <543EDE61.6090801@redhat.com> References: <1413222308-25753-1-git-send-email-dmalcolm@redhat.com> <1413222308-25753-3-git-send-email-dmalcolm@redhat.com> <543EB0AA.5030903@redhat.com> <1413397540.9513.125.camel@surprise> <543EDE61.6090801@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-SW-Source: 2014-q4/txt/msg00039.txt.bz2 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)