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

[Andrea Corallo]

Eli Zaretskii <address@hidden> writes:

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

Yeah sure, I clearly see your point now.

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

Is it really this the problem or is Nicolas who wants to use two
different setups for some reason?  I guess he will explain shortly.

BTW this is what I log with my libgccjit for the driver options:

 JIT:       argv[0]: x86_64-pc-linux-gnu-gcc-10.0.1
 JIT:       argv[1]: -m64
 JIT:       argv[2]: -shared
 JIT:       argv[3]: /tmp/libgccjit-TO70rk/fake.s
 JIT:       argv[4]: -o
 JIT:       argv[5]: /tmp/libgccjit-TO70rk/fake.so
 JIT:       argv[6]: -fno-use-linker-plugin

> Someone, perhaps you, mentioned -nostdlib option to gcc,

Wasn't me :)

Andrea

--
address@hidden