[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [WIP] Port feature/native-comp to Windows.

From: Eli Zaretskii
Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows.
Date: Sun, 10 May 2020 21:30:52 +0300

> From: Andrea Corallo <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sun, 10 May 2020 11:14:11 -0700
> libgccjit when has produced the .s file has to invoke the "driver".
> This is in GCC jargon the usual gcc executable that his the program that
> is responsible for calling cc1 as and ld.
> libgccjit can invoke the driver in two ways, one is using the embedded
> one (default) or it can search for an external driver (the system gcc
> executable).  AFAIU when the driver takes over the conventional logic to
> identify support library is used by the linker.

And on GNU/Linux we use the default, i.e. the embedded driver?

Does the embedded driver know where GCC is installed on the system
where Emacs runs, and where to find the support libraries?  If not,
why not?  After all, I presume libgccjit is just one component of the
GCC installation, so it shares the environment and the search lists
with the locally installed gcc driver, no?

If for Windows we decide to use the external driver, i.e. the gcc.exe
installed on the end-user's system, does it solve all the problems
with finding the auxiliary programs and support libraries?  If so, I
think this way is better, at least on MS-Windows (if not on all

> Using gcc_jit_context_add_driver_option you can pass parameters to the
> driver that will forward them to the linker.

Sure, but it sounds like knowing what those parameters are is not a
simple job.  Although I still don't seem to understand why, silly me.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]