On Thu, 17 Mar 2022, LIU Hao wrote:
在 2022/3/16 23:25, Biswapriyo Nath 写道:
As you wish. Here is the 2nd update.
I suddenly realize this is C++ source.
Thanks for catching this issue!
This may pull in libstdc++ and libgcc (or libc++, whatever).
Microsoft docs say this function returns a string that the user has to
`delete[]` so I suspect we can't rewrite this function in C, only because we
can't allocate C++ memory there.
On the other hand, this only makes a difference when one wants to build the
CRT without a C++ compiler. This also doesn't seem the case, as both GCC and
Clang are written in C++, so a C++ compiler is required to build the
compiler, and probably others.
This is an incorrect argument. What tools you need for building the
compiler that targets mingw, and the compiler that targets mingw itself
are two separate things.
Consider if building a cross compiler from Linux to Windows. As GCC is
written in C++, you need a Linux C++ compiler to build GCC. But if you
only are going to build Windows applications in C, it's quite valid to
configure GCC with --enable-languages=c, omitting C++ support in the
mingw-targeting GCC.
Then secondly; mingw-w64-crt is layered below any C++ standard library
(libstdc++, libc++), so things in mingw-w64-crt cannot depend on the C++
standard library. This means that you can't include C++ standard headers.
(But this patch doesn't, so it's ok in that sense.)
(Consider if bootstrapping a cross compiler; at the point when building
mingw-w64-crt, we have only just built the GCC/G++ compiler, but we have
not built libstdc++/libgcc yet, nor have we installed the libstdc++
headers, because those need mingw-w64-crt to be built first.)
However, since this (like everything else in mingw-w64-crt) only is built
as static libraries, using C++ without using the standard library can
work, and nobody will try to link it in before the C++ standard library
has been built.
In the C++ source file, there's a call to "operator new"; this is a
standard C++ operator which doesn't require including any header, but the
actual implementation of this function (which only is needed later when
linking the library) is provided by the C++ standard library. As it isn't
dependent on the library headers, it's also agnostic between libstdc++ and
libc++.
Our configure script already checks for a C++ compiler (AC_PROG_CXX), so I
considered whether we should add a condition around this library, so we
only build it if we actually found a C++ compiler.
However, autotools does some dubious choices here. If I'm configuring a
cross compiler, and I do have x86_64-w64-mingw32-gcc but I don't have
x86_64-w64-mingw32-g++ because I built only with --enable-languages=c, the
configure script does this detection:
checking for x86_64-w64-mingw32-g++... no
checking for x86_64-w64-mingw32-c++... no
checking for x86_64-w64-mingw32-gpp... no
checking for x86_64-w64-mingw32-aCC... no
checking for x86_64-w64-mingw32-CC... no
checking for x86_64-w64-mingw32-cxx... no
checking for x86_64-w64-mingw32-cc++... no
checking for x86_64-w64-mingw32-cl.exe... no
checking for x86_64-w64-mingw32-FCC... no
checking for x86_64-w64-mingw32-KCC... no
checking for x86_64-w64-mingw32-RCC... no
checking for x86_64-w64-mingw32-xlC_r... no
checking for x86_64-w64-mingw32-xlC... no
checking for x86_64-w64-mingw32-clang++... no
checking for g++... g++
configure: WARNING: using cross tools not prefixed with host triplet
So instead of concluding that it didn't find any C++ compiler, it picks up
the host (in my case, linux) C++ compiler instead. It gives a warning
about it, but still proceeds, and any condition in the code would be
enabled as it _did_ find a C++ commpiler. Building then later fails like
this:
g++ -DHAVE_CONFIG_H -I. -I.. -m64
"-I/opt/gcc-mingw/x86_64-w64-mingw32/include"
-Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -g -O2 -MT libsrc/lib64_libcomsupp_a-comsupp.o -MD -MP -MF
libsrc/.deps/lib64_libcomsupp_a-comsupp.Tpo -c -o libsrc/lib64_libcomsupp_a-comsupp.o `test -f
'libsrc/comsupp.cpp' || echo '../'`libsrc/comsupp.cpp
g++: error: unrecognized command line option '-m64'
Makefile:69208: recipe for target 'libsrc/lib64_libcomsupp_a-comsupp.o' failed
This was on aarch64 linux, where GCC doesn't support the -m64 option. On
x86_64 linux, where GCC does support the option, compiling of the file
instead fails because it can't understand the Windows headers that are
included when building it.
Thus, TL;DR, technically this particular instance of C++ in mingw-w64-crt
could be tolerable, but we must be very very careful about any addition of
new C++ sources there. But the patch as is does indeed break setting up
environments without a C++ compiler, which worked just fine before.
Jacek, do you have any advice on autotools, for making it not accidentally
pick up incorrect (host) compilers when the real intended one is missing?
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
