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

[Eli Zaretskii]

> From: Andrea Corallo <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sun, 10 May 2020 11:54:05 -0700
> 
> 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.

But the linker doesn't usually know where to find the libraries,
because the libraries are part of the GCC installation, not of the
Binutils installation.  That's why gcc always tells the linker where
to find the libraries, via the -L switch.  Try compiling a trivial
program with "gcc -v", and you will see how the linker is invoked: gcc
spoon-feeds it with all the directories on the library search path
(you can see those directories if you invoke "gcc -print-search-paths").

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

See above.  What _I_ don't understand is why cannot libgccjit feed the
linker with the same -L switches that gcc does.

Someone, perhaps you, mentioned -nostdlib option to gcc, which might
be the answer to this question, but then why use -nostdlib at all?