From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10153 invoked by alias); 15 Oct 2014 21:33:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-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-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-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Oct 2014 21:33:27 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FLXPCZ012578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 17:33:25 -0400 Received: from [10.3.233.107] (vpn-233-107.phx2.redhat.com [10.3.233.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FLXOKQ019239; Wed, 15 Oct 2014 17:33:25 -0400 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, 15 Oct 2014 21:46: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-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01438.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)