Thread: [Mingw-w64-public] [PATCH] crt: Add comsupp library

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

在 2022-03-11 15:19, Biswapriyo Nath 写道:
> 0001-crt-Add-comsupp-library.patch
> 
>  From 809cd7851d20d423fc1e9dd9df6cd107d343d7fc Mon Sep 17 00:00:00 2001
> From: Biswapriyo Nath<nat...@gm...>
> Date: Fri, 11 Mar 2022 12:47:59 +0530
> Subject: [PATCH] crt: Add comsupp library
> 
> Required for unrar project
> 
> Signed-off-by: Biswapriyo Nath<nat...@gm...>
> ---
>   mingw-w64-crt/Makefile.am        | 17 +++++++
>   mingw-w64-crt/libsrc/comsupp.cpp | 84 ++++++++++++++++++++++++++++++++
>   2 files changed, 101 insertions(+)
>   create mode 100644 mingw-w64-crt/libsrc/comsupp.cpp
> 

I am not sure whether we can take this GPL'd piece of code from ReactOS without confirmation. Would 
please ask ReactOS developers to disclaim copy right of it?

-- 
Best regards,
LIU Hao

Here are the updated patch files.

在 2022-03-16 22:22, Biswapriyo Nath 写道:
> diff --git a/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt b/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt
> index ca6a077..dcf0807 100644
> --- a/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt
> +++ b/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt

I am a bit unclear about this hunk: The purpose of having two COPYING files is described in 
COPYING.MinGW-w64.txt:

   The copyright and license notices have been divided in two files:
   The notices in COPYING.MinGW-w64.txt (this file) apply only to
   MinGW-w64 itself. These don't apply to the binaries built with
   MinGW-w64 unless you specifically tell MinGW-w64 to link against
   these parts, for example, by enabling profiling code.

This description is a bit obscure but I hope I can interpret it a bit: The runtime is always 
compiled into any binary files that are linked against mingw-w64, so the runtime notices shall 
always be carried. The non-runtime part is only compiled into binary files that use them as told by 
our users, so the non-runtime notices are not always needed.

AFAICT this newly added notice should be categorized as a non-runtime notice. What do you think?

-- 
Best regards,
LIU Hao

As you wish. Here is the 2nd update.

在 2022/3/16 23:25, Biswapriyo Nath 写道:
> As you wish. Here is the 2nd update.

I suddenly realize this is C++ source. 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.

Not sure about what others may think; I am okay with this patch. If any issues emerge after this 
change, we will have to turn these into inline functions.

-- 
Best regards,
LIU Hao

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

On 3/17/22 09:56, Martin Storsjö wrote:
>
> 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? 

Yeah, this autotools behaviour looks buggy. I don't know how it's 
intended to be used, I'm CCing NightStrike hoping that he knows better 
what's going on. I can see some possible solution, but it would be nice 
to understand root of the problem:

- We could use something like AC_COMPILE_IFELSE with input like:

#ifndef __MINGW32__

#error ...

#endif

and skip C++ sources if that test fails.

- We could just get rid of AC_PROG_CXX macro and instead check if $(CC) 
supports -xc++ option. If it does, use it for C++ sources, skip otherwise.

- Use inline implementation. Those functions look easy enough for that. 
I guess the dependency is pulled by our comutil.h, or is it the 
application itself that calls them?

Thanks,

Jacek

If this comsupp library can not be integrated with main crt libraries,
is it possible to add this library in mingw-w64-libraries folder and
then add option (e.g. --enable-extras) in configure.ac to build from
that folder?

在 2022-03-20 12:50, Biswapriyo Nath 写道:
> If this comsupp library can not be integrated with main crt libraries,
> is it possible to add this library in mingw-w64-libraries folder and
> then add option (e.g. --enable-extras) in configure.ac to build from
> that folder?

It is also what Microsoft people do. Thus I think it is doable.

-- 
Best regards,
LIU Hao

On Sun, 20 Mar 2022, LIU Hao wrote:

> 在 2022-03-20 12:50, Biswapriyo Nath 写道:
>> If this comsupp library can not be integrated with main crt libraries,
>> is it possible to add this library in mingw-w64-libraries folder and
>> then add option (e.g. --enable-extras) in configure.ac to build from
>> that folder?
>
> It is also what Microsoft people do. Thus I think it is doable.

Sure, moving it out elsewhere is an option too.

I wouldn't entirely rule out putting it in mingw-w64-crt either, but we'd 
need to tweak the C++ compiler detection code - I haven't had time to try 
that yet.

// Martin

在 2022-03-20 16:39, Martin Storsjö 写道:
> 
> Sure, moving it out elsewhere is an option too.
> 
> I wouldn't entirely rule out putting it in mingw-w64-crt either, but we'd need to tweak the C++ 
> compiler detection code - I haven't had time to try that yet.
> 

I recommend that we don't bring C++ into the CRT, unless we decide to rewrite everything with C++ 
which is impractical in foreseeable future.

Having a standalone library also eliminates the need of having another chapter in COPYING - only the 
library itself needs it.

-- 
Best regards,
LIU Hao

Thread: [Mingw-w64-public] [PATCH] crt: Add comsupp library

A complete runtime environment for gcc

mingw-w64-public