* Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver [not found] <c35cf6d3-0eab-92fa-458d-2a544b7f9e66@ubuntu.com> @ 2019-01-01 0:00 ` David Malcolm 2019-01-01 0:00 ` Matthias Klose 0 siblings, 1 reply; 5+ messages in thread From: David Malcolm @ 2019-01-01 0:00 UTC (permalink / raw) To: Matthias Klose, GCC Patches, jit On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: > Fix PR jit/87808, the embedded driver still needing the external gcc > driver to > find the gcc_lib_dir. This can happen in a packaging context when > libgccjit > doesn't depend on the gcc package, but just on binutils and libgcc- > dev packages. > libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, > but that > doesn't seem to be very portable. > > Ok for the trunk and the branches? > > Matthias [CCing the jit list] I've been trying to reproduce this bug in a working copy, and failing. Matthias, do you have a recipe you've been using to reproduce this? Thanks Dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver 2019-01-01 0:00 ` [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver David Malcolm @ 2019-01-01 0:00 ` Matthias Klose 2021-07-12 21:00 ` Matthias Klose 0 siblings, 1 reply; 5+ messages in thread From: Matthias Klose @ 2019-01-01 0:00 UTC (permalink / raw) To: David Malcolm, GCC Patches, jit On 22.03.19 23:00, David Malcolm wrote: > On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >> Fix PR jit/87808, the embedded driver still needing the external gcc >> driver to >> find the gcc_lib_dir. This can happen in a packaging context when >> libgccjit >> doesn't depend on the gcc package, but just on binutils and libgcc- >> dev packages. >> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >> but that >> doesn't seem to be very portable. >> >> Ok for the trunk and the branches? >> >> Matthias > > [CCing the jit list] > > I've been trying to reproduce this bug in a working copy, and failing. > > Matthias, do you have a recipe you've been using to reproduce this? the JIT debug log shows the driver names that it wants to call. Are you sure that this driver isn't available anywhere? I configure the gcc build with --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only available in one place, /usr/bin. Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver 2019-01-01 0:00 ` Matthias Klose @ 2021-07-12 21:00 ` Matthias Klose 2021-07-13 6:41 ` Richard Biener 0 siblings, 1 reply; 5+ messages in thread From: Matthias Klose @ 2021-07-12 21:00 UTC (permalink / raw) To: David Malcolm, GCC Patches, jit On 3/26/19 12:52 PM, Matthias Klose wrote: > On 22.03.19 23:00, David Malcolm wrote: >> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >>> Fix PR jit/87808, the embedded driver still needing the external gcc >>> driver to >>> find the gcc_lib_dir. This can happen in a packaging context when >>> libgccjit >>> doesn't depend on the gcc package, but just on binutils and libgcc- >>> dev packages. >>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >>> but that >>> doesn't seem to be very portable. >>> >>> Ok for the trunk and the branches? >>> >>> Matthias >> >> [CCing the jit list] >> >> I've been trying to reproduce this bug in a working copy, and failing. >> >> Matthias, do you have a recipe you've been using to reproduce this? > > the JIT debug log shows the driver names that it wants to call. Are you sure > that this driver isn't available anywhere? I configure the gcc build with > --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only > available in one place, /usr/bin. > > Matthias David, the bug report now has two more comments from people that the current behavior is broken. Please could you review the patch? Thanks, Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver 2021-07-12 21:00 ` Matthias Klose @ 2021-07-13 6:41 ` Richard Biener 2021-07-14 5:42 ` Matthias Klose 0 siblings, 1 reply; 5+ messages in thread From: Richard Biener @ 2021-07-13 6:41 UTC (permalink / raw) To: Matthias Klose; +Cc: David Malcolm, GCC Patches, jit On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose <doko@ubuntu.com> wrote: > > On 3/26/19 12:52 PM, Matthias Klose wrote: > > On 22.03.19 23:00, David Malcolm wrote: > >> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: > >>> Fix PR jit/87808, the embedded driver still needing the external gcc > >>> driver to > >>> find the gcc_lib_dir. This can happen in a packaging context when > >>> libgccjit > >>> doesn't depend on the gcc package, but just on binutils and libgcc- > >>> dev packages. > >>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, > >>> but that > >>> doesn't seem to be very portable. > >>> > >>> Ok for the trunk and the branches? > >>> > >>> Matthias > >> > >> [CCing the jit list] > >> > >> I've been trying to reproduce this bug in a working copy, and failing. > >> > >> Matthias, do you have a recipe you've been using to reproduce this? > > > > the JIT debug log shows the driver names that it wants to call. Are you sure > > that this driver isn't available anywhere? I configure the gcc build with > > --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only > > available in one place, /usr/bin. > > > > Matthias > > David, the bug report now has two more comments from people that the current > behavior is broken. Please could you review the patch? I think libgccjit should use the same strathegy for finding the install location like the driver does itself. I couldn't readily decipher its magic but at least there's STANDARD_EXEC_PREFIX which seems to be used as possible fallback. In particular your patch doesn't seem to work with a DESTDIR=<path> install? Can we instead add a --with-gccjit-install-dir= or sth like that (whatever path to whatever files the JIT exactly looks for)? Richard. > Thanks, Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver 2021-07-13 6:41 ` Richard Biener @ 2021-07-14 5:42 ` Matthias Klose 0 siblings, 0 replies; 5+ messages in thread From: Matthias Klose @ 2021-07-14 5:42 UTC (permalink / raw) To: Richard Biener; +Cc: David Malcolm, GCC Patches, jit On 7/13/21 8:41 AM, Richard Biener wrote: > On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose <doko@ubuntu.com> wrote: >> >> On 3/26/19 12:52 PM, Matthias Klose wrote: >>> On 22.03.19 23:00, David Malcolm wrote: >>>> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >>>>> Fix PR jit/87808, the embedded driver still needing the external gcc >>>>> driver to >>>>> find the gcc_lib_dir. This can happen in a packaging context when >>>>> libgccjit >>>>> doesn't depend on the gcc package, but just on binutils and libgcc- >>>>> dev packages. >>>>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >>>>> but that >>>>> doesn't seem to be very portable. >>>>> >>>>> Ok for the trunk and the branches? >>>>> >>>>> Matthias >>>> >>>> [CCing the jit list] >>>> >>>> I've been trying to reproduce this bug in a working copy, and failing. >>>> >>>> Matthias, do you have a recipe you've been using to reproduce this? >>> >>> the JIT debug log shows the driver names that it wants to call. Are you sure >>> that this driver isn't available anywhere? I configure the gcc build with >>> --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only >>> available in one place, /usr/bin. >>> >>> Matthias >> >> David, the bug report now has two more comments from people that the current >> behavior is broken. Please could you review the patch? > > I think libgccjit should use the same strathegy for finding the install location > like the driver does itself. I couldn't readily decipher its magic but at least > there's STANDARD_EXEC_PREFIX which seems to be used as possible > fallback. No, it's crtbeginS.o, and libgcc.* which are are not found in the STANDARD_EXEC_PREFIX. > In particular your patch doesn't seem to work with a DESTDIR=<path> > install? it does. usually you build as configure && make && make install with a DESTDIR set for only the last step, which doesn't rebuild any object file. > Can we instead add a --with-gccjit-install-dir= or sth like that (whatever > path to whatever files the JIT exactly looks for)? that should be possible, moving the definition of FALLBACK_GCC_EXEC_PREFIX from the Makefile to a value specified by a configure value. Or is there already a macro, that doesn't get prefixed by DESTDIR? Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-14 5:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <c35cf6d3-0eab-92fa-458d-2a544b7f9e66@ubuntu.com> 2019-01-01 0:00 ` [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver David Malcolm 2019-01-01 0:00 ` Matthias Klose 2021-07-12 21:00 ` Matthias Klose 2021-07-13 6:41 ` Richard Biener 2021-07-14 5:42 ` Matthias Klose
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).