Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2021-07-13 Thread Matthias Klose
On 7/13/21 8:41 AM, Richard Biener wrote:
> On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose  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=
> 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


Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2021-07-13 Thread Richard Biener via Gcc-patches
On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose  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=
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


Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2021-07-12 Thread Matthias Klose
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


Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2019-03-26 Thread Matthias Klose
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


Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2019-03-22 Thread David Malcolm
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


[patch] PR jit/87808: Allow libgccjit to work without an external gcc driver

2019-03-21 Thread Matthias Klose
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
# DP: Fix PR jit/87808.

	* Make-lang.in (CFLAGS-jit/jit-playback.o): Pass fallback
	  GCC_EXEC_PREFIX.
	* jit-playback.c (invoke_embedded_driver): Use fallback GCC_EXEC_PREFIX
	  when external driver is not present.

--- a/src/gcc/jit/Make-lang.in
+++ b/src/gcc/jit/Make-lang.in
@@ -84,6 +84,9 @@
 	jit/jit-spec.o \
 	gcc.o
 
+CFLAGS-jit/jit-playback.o += \
+	-DFALLBACK_GCC_EXEC_PREFIX=\"$(libdir)/gcc/$(target_subdir)/$(version)\"
+
 # Use strict warnings for this front end.
 jit-warn = $(STRICT_WARN)
 
--- a/src/gcc/jit/jit-playback.c
+++ b/src/gcc/jit/jit-playback.c
@@ -39,6 +39,7 @@
 #include "opt-suggestions.h"
 #include "gcc.h"
 #include "diagnostic.h"
+#include "file-find.h"
 
 #include 
 
@@ -2482,7 +2483,31 @@
 playback::context::
 invoke_embedded_driver (const vec  *argvec)
 {
+  static char* gcc_driver_file = NULL;
+
   JIT_LOG_SCOPE (get_logger ());
+
+  /* process_command() uses make_relative_prefix(), searches PATH
+ for the external driver, which might not be found.  In this case
+ fall back to the configured default.  */
+#ifdef FALLBACK_GCC_EXEC_PREFIX
+  if (gcc_driver_file == NULL && ::getenv ("GCC_EXEC_PREFIX") == NULL)
+{
+  struct path_prefix path;
+
+  prefix_from_env ("PATH", );
+  gcc_driver_file = find_a_file (, gcc_driver_name, X_OK);
+  if (gcc_driver_file == NULL)
+{
+	  char *str = concat ("GCC_EXEC_PREFIX=",
+			  FALLBACK_GCC_EXEC_PREFIX, NULL);
+	  ::putenv (str);
+	  log ("gcc driver %s not found, using fallback GCC_EXEC_PREFIX=%s",
+	   gcc_driver_name, FALLBACK_GCC_EXEC_PREFIX);
+}
+}
+#endif
+
   driver d (true, /* can_finalize */
 	false); /* debug */
   int result = d.main (argvec->length (),