On 2017/5/4 23:54, J.W. Jagersma wrote:
> Well it got to the next stage after I did this:
>> ln -s /mingw64/x86_64-w64-mingw32/include
/home/jw/build-gcc-mingw64/x86_64-w64-mingw32/include
If you are building a native compiler which does not recognize POSIX-ish
paths, you probably have to replace that /mingw thing with a real,
absolute path, as in
<https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L116>.
The previous 'cpp fails sanity check' error might be caused by the
inconsistency between hardcoded header paths and the real paths (bug
70936 does not take place if the hardcoded path is valid).
>
> But now it's stuck on an undefined reference:
>>
C:\Users\JW\AppData\Local\Temp\ccrMv82H.ltrans0.ltrans.o:<artificial>:(.text+0x7428):
undefined reference to `stpcpy'
>> collect2.exe: error: ld returned 1 exit status
>> make[4]: *** [Makefile:377: liblto_plugin.la] Error 1
>> make[4]: Leaving directory '/home/JW/build-gcc-mingw64/lto-plugin'
>> make[3]: *** [Makefile:291: all] Error 2
>> make[3]: Leaving directory '/home/JW/build-gcc-mingw64/lto-plugin'
>> make[2]: *** [Makefile:16108: all-stage2-lto-plugin] Error 2
>> make[2]: Leaving directory '/home/JW/build-gcc-mingw64'
>> make[1]: *** [Makefile:23982: stage2-bubble] Error 2
>> make[1]: Leaving directory '/home/JW/build-gcc-mingw64'
>> make: *** [Makefile:945: all] Error 2
>
> Not sure what to do at this point. Shouldn't stpcpy be a part of the
> mingw64 runtime library?
>
No. It is a POSIX function but not a standard C function so our CRT is
not responsible for implementing it. I guess you are probaby linking
against MSYS libraries (which provide POSIX functions) at stage1 and
configure mistakenly reports `stpcpy()` is available, but since you are
building a native Windows compiler, it is not.
--
Best regards,
LH_Mouse
