Re: [feature/native-comp] breakage on build

[Eli Zaretskii]

> From: Phillip Lord <phillip.lord@russet.org.uk>
> Cc: akrl@sdf.org,  emacs-devel@gnu.org
> Date: Fri, 05 Feb 2021 21:50:24 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Phillip Lord <phillip.lord@russet.org.uk>
> >> Cc: akrl@sdf.org,  emacs-devel@gnu.org
> >> Date: Fri, 05 Feb 2021 20:37:31 +0000
> >> 
> >> I have checked the library paths as well as I know how (gcc
> >> --print-search-dirs). I have reformatted the output with some new lines
> >> to make it readable.
> >
> > I'm not sure I understand: do these directories really exist, and do
> > they hold the libraries gcc is looking for?  I mean these directories:
> 
> No. The lib/gcc didn't exist at first. If they did hold the libraries
> GCC was looking for, I presume it would work. I have no idea where all
> that strangeness with relative paths which look to me like they resolve
> to the same places repeatedly comes from.

I believe this is just the standard GCC search path on MS-Windows.

> > If they do exist, does it mean you duplicated the entire MinGW GCC
> > installation under the same directory that is the parent of the
> > Emacs's bin/ directory?
> 
> I have tried copying /msys64/mingw64/lib/gcc into the Emacs installation
> at /lib, yes.

/msys64/mingw64/lib/gcc is not enough, you also need some of the
/msys64/mingw64/libexec/gcc (assuming MinGW64 has it -- I don't use
MinGW64, so I cannot check).

> > What does the following command produce?
> >
> >   gcc -print-file-name=crtbegin.o
> 
> gcc -print-file-name=crtbegin.o
> c:/Users/Administrator/Desktop/emacs-28.0.50-snapshot-feature_native-comp-windows-2021-02-04/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/crtbegin.o
> 
> This file does exist.

Then I admit I don't understand this part of the error messages:

> compiling to 
> c:/Users/Administrator/AppData/Roaming/.emacs.d/eln-cache/28.0.50-14889799/cl-lib-8b938900-d1df28b7.eln
> x86_64-w64-mingw32-gcc-10.2.0: fatal error: cannot execute 'as': 
> CreateProcess: No such file or directory
> compilation terminated.
> ld: cannot find dllcrt2.o: No such file or directory
> ld: cannot find crtbegin.o: No such file or directory
> ld: cannot find -lmingw32
> ld: cannot find -lgcc_s
> ld: cannot find -lgcc
> ld: cannot find -lmoldname
> ld: cannot find -lmingwex
> ld: cannot find -lmsvcrt
> ld: cannot find -lkernel32
> ld: cannot find -lpthread
> ld: cannot find -ladvapi32
> ld: cannot find -lshell32
> ld: cannot find -luser32
> ld: cannot find -lkernel32
> ld: cannot find -lmingw32
> ld: cannot find -lgcc_s
> ld: cannot find -lgcc
> ld: cannot find -lmoldname
> ld: cannot find -lmingwex
> ld: cannot find -lmsvcrt
> ld: cannot find -lkernel32
> ld: cannot find crtend.o: No such file or directory

GCC should have instructed ld.exe where to look for the libraries
mentioned in this error message.  If crtbegin.o exists at the location
where GCC expects it to be (and I presume the rest of the libraries
mentioned in the above message also exist there -- do they?), then why
didn't ld.exe find them?

Is there a way to invoke JIT compiler so that the -v switch is passed
to ld.exe as well?  On the command line, "gcc -v" accomplishes that.
This will show you which directories ld.exe searches for its
libraries.

Also note that in that invocation GCC didn't find as.exe, so it could
be that these error messages are triggered by that and not by actually
missing the libraries.

> > Alternatively, could it be that under the mingw64 shell Emacs invokes
> > a different copy of gcc/libgccjit, the one that is in its "normal"
> > installation tree and not in the Emacs tree?
> 
> Yes. I do not know how much or how little of the mingw64 install that
> Emacs is using; it could be a missing DLL, config file anything at
> all. But, the -no-deps version of Emacs happily does native-comp when
> launched from inside a mingw64 shell.

Then maybe you should start by duplicating the full installation of
GCC, Binutils, and MinGW runtime under the same directory where you
have bin/emacs.exe.  Once you install that, see if native-comp works
outside of the mingw64 shell.  If it does, then you can start removing
files and directories that are not needed, which will hopefully leave
you with the minimum subset of the mingw64 installation required for
native-comp.