[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: Andrea Corallo
Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows.
Date: Sun, 10 May 2020 11:54:05 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> 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?

The embedde driver is just some code some code in libgccjit that act as
the original gcc executable so has not need to be located.  For the
support libraries is the linker that does that conventionally.

You can even log the ld invocation done by the embedded drive is nothing
magical.  Finally the linker is just the system one.

> 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?

That is my understanding.

> 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
> systems).
>> 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.

Me too I do not understand why ld is not doing the expected job, I guess
I've to re-read the thread.



reply via email to

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