[Mingw-w64-public] SDKDDKVer.h default target version
I was recently dealing with a project that seems to have been creatd from a Visual Studio project template. It includes a "targetver.h" file with the following comments: // Including SDKDDKVer.h defines the highest available Windows platform. // If you wish to build your application for a previous Windows platform, include WinSDKVer.h and // set the _WIN32_WINNT macro to the platform you wish to support before including SDKDDKVer.h. However, in mingw-w64, including SDKDDKVer.h doesn't result in the highest available Windows platform, or even the default as specified to mingw-w64-headers' configure script. It seems to hardcode a default of "WS03" aka 0x0502. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Add mi import library
> That's exactly how it's supposed to work at least.
Thanks for the verification. I have removed the
mingw-w64-crt/lib32/mi.def and attached the updated patch file.
From 654aeb84c1138777a804ca236364fe4836d6ae12 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Mon, 3 Apr 2023 10:25:46 +0530
Subject: [PATCH 2/2] crt: Add mi import library
Required for https://github.com/cloudbase/PyMI.git
Signed-off-by: Biswapriyo Nath
---
mingw-w64-crt/{libarm32 => lib-common}/mi.def | 2 +-
mingw-w64-crt/lib32/Makefile.am | 1 +
mingw-w64-crt/lib64/Makefile.am | 1 +
mingw-w64-crt/libarm64/Makefile.am| 1 +
4 files changed, 4 insertions(+), 1 deletion(-)
rename mingw-w64-crt/{libarm32 => lib-common}/mi.def (80%)
diff --git a/mingw-w64-crt/libarm32/mi.def b/mingw-w64-crt/lib-common/mi.def
similarity index 80%
rename from mingw-w64-crt/libarm32/mi.def
rename to mingw-w64-crt/lib-common/mi.def
index b05acf3..c0e500e 100644
--- a/mingw-w64-crt/libarm32/mi.def
+++ b/mingw-w64-crt/lib-common/mi.def
@@ -1,7 +1,7 @@
;
; Definition file of mi.dll
; Automatic generated by gendef
-; written by Kai Tietz 2008-2014
+; written by Kai Tietz 2008
;
LIBRARY "mi.dll"
EXPORTS
diff --git a/mingw-w64-crt/lib32/Makefile.am b/mingw-w64-crt/lib32/Makefile.am
index 4bfa4ee..4383d27 100644
--- a/mingw-w64-crt/lib32/Makefile.am
+++ b/mingw-w64-crt/lib32/Makefile.am
@@ -177,6 +177,7 @@ lib32_DATA += %reldir%/libmfplay.a
lib32_DATA += %reldir%/libmfreadwrite.a
lib32_DATA += %reldir%/libmfsensorgroup.a
lib32_DATA += %reldir%/libmgmtapi.a
+lib32_DATA += %reldir%/libmi.a
lib32_DATA += %reldir%/libmincore.a
lib32_DATA += %reldir%/libmmdevapi.a
lib32_DATA += %reldir%/libmpr.a
diff --git a/mingw-w64-crt/lib64/Makefile.am b/mingw-w64-crt/lib64/Makefile.am
index c4db729..fea91f6 100644
--- a/mingw-w64-crt/lib64/Makefile.am
+++ b/mingw-w64-crt/lib64/Makefile.am
@@ -305,6 +305,7 @@ lib64_DATA += %reldir%/libmfc42u.a
lib64_DATA += %reldir%/libmfreadwrite.a
lib64_DATA += %reldir%/libmfsensorgroup.a
lib64_DATA += %reldir%/libmgmtapi.a
+lib64_DATA += %reldir%/libmi.a
lib64_DATA += %reldir%/libmidimap.a
lib64_DATA += %reldir%/libmigism.a
lib64_DATA += %reldir%/libmiglibnt.a
diff --git a/mingw-w64-crt/libarm64/Makefile.am
b/mingw-w64-crt/libarm64/Makefile.am
index 6b91cc1..0f3cddb 100644
--- a/mingw-w64-crt/libarm64/Makefile.am
+++ b/mingw-w64-crt/libarm64/Makefile.am
@@ -164,6 +164,7 @@ libarm64_DATA += %reldir%/libmfplay.a
libarm64_DATA += %reldir%/libmfreadwrite.a
libarm64_DATA += %reldir%/libmfsensorgroup.a
libarm64_DATA += %reldir%/libmgmtapi.a
+libarm64_DATA += %reldir%/libmi.a
libarm64_DATA += %reldir%/libmidimap.a
libarm64_DATA += %reldir%/libmincore.a
libarm64_DATA += %reldir%/libmlang.a
--
2.40.0
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] genpeimg: fix build error with clang v16
On 4/2/23 15:40, Christoph Reiter wrote:
Building genpeimg with clang v16 fails like:
error: implicit truncation from 'int' to a one-bit wide bit-field changes value
from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
pe->is_64bit = 1;
is_64bit is always ever comapred against 0 in our case, so the value change
doesn't matter, but let's just make it unsigned to fix the error and avoid
any future confusion.
The same is theoretically true for is_bigendian, but that currently
never set to 1 in any place. Make it unsigned as well while at it.
---
mingw-w64-tools/genpeimg/src/img.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-tools/genpeimg/src/img.h
b/mingw-w64-tools/genpeimg/src/img.h
index 6e969a175..dd47a0f4b 100644
--- a/mingw-w64-tools/genpeimg/src/img.h
+++ b/mingw-w64-tools/genpeimg/src/img.h
@@ -67,8 +67,8 @@ typedef struct pe_image {
size_t optional_hdr_pos;
size_t section_list;
size_t section_list_sz; /* Each section entry has 40 bytes size. */
- int is_64bit : 1;
- int is_bigendian : 1;
+ unsigned int is_64bit : 1;
+ unsigned int is_bigendian : 1;
} pe_image;
pe_image *peimg_create (file_image *pimg);
Thanks, pushed to master branch.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Add mi import library
On Mon, 3 Apr 2023, Biswapriyo Nath wrote: If not, couldn't the lib32 variant also be omitted? I am not sure about that. There is a rule `lib32/lib%.a: lib-common/%.def` in mingw-w64-crt/Makefile.am. I am not certain that the build system will grab the lib-common one when lib32 is absent. That's exactly how it's supposed to work at least. For most libraries in lib32, we have a separate copy due to the stdcall suffixes, but for the ones where there are no such suffixes (like msvcrt and ucrt) we already use the copies from lib-common. If we wanted to spend more effort on it, we could also handle the stdcall suffixes with templates, to allow sharing def files across all architectures. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
Hi everyone, On 03/04/2023 07:04, LIU Hao wrote: > 在 2023/4/3 16:55, Vittorio Romeo 写道: >> Hello everyone, >> Hope you are doing well. >> >> I've encountered and reported a bug related to explicit template >> instantiations and dllexport using the latest version of GCC on >> MinGW/MSYS2: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 > > I don't think it's a bug. There are two issues in your testcase, one is > that > > extern template struct __declspec(dllexport) S; > > is a declaration, and nothing can be exported from a declaration (you > export the definition instead). I believe this may be correct as per the standard, https://developercommunity.visualstudio.com/t/c11-extern-templates-doesnt-work-for-class-templat/157868#T-N355261 but not according to MinGW's own semantics: https://reviews.llvm.org/D61118 I recall we had to work around it in Krita to avoid a possible runtime symbol clash/crash: https://invent.kde.org/graphics/krita/-/commit/0ca27275ee9c8e7a4a2223cc4e66d12e95517edc > > The other is that `g()` is an implicit inline function. An inline > function can only be exported when it is emitted as a non-inline copy, > for example, when optimization is not enabled, or when its address is > taken, or when it is virtual and the class has a non-pure non-inline > virtual function (a.k.a. the key function) which instantiates its vtable. > > > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Best regards, amyspark -- amyspark 🌸 https://www.amyspark.me ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
在 2023/4/3 18:33, Vittorio Romeo 写道: My use case is as follows. I have a class template `S` with implicit inline functions in `lib.h`. To improve compilation times, I want to explicitly instantiate common specializations of this class template in `lib.cpp`. In order to do so, I want to provide an explicit instantiation declaration (`extern template`) of `S` in `lib.h`, and an explicit instantiation definition of `S` in `lib.cpp`. Now, I expect that every consumer linking against `lib` should be able to use `S` without having to fully instantiate it. That's perfect valid use. I did some experiments, compared results from explicit instantiations with non-template functions (which got exported correctly), and also with what was generated on Linux. Indeed GCC generates out-of-line copies for inline functions along with the explicit instantiation, and calls to such functions no longer result in out-of-line copies on their own. In this case, GCC should have exported such instantiated copies. I have replied on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380, but not sure whether there have been people working it yet. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: Add noreturn attributes to the _assert/_wassert functions
This allows the compiler to understand that constructs such as
assert(0) won't return.
This fixes warnings (treated as errors) about a missing return in
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.0/libcxxabi/test/cxa_vec_new_overflow_PR41395.pass.cpp#L21
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/assert.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/crt/assert.h b/mingw-w64-headers/crt/assert.h
index 6d33eacfb..a8cfb2e83 100644
--- a/mingw-w64-headers/crt/assert.h
+++ b/mingw-w64-headers/crt/assert.h
@@ -21,8 +21,8 @@
extern "C" {
#endif
-_CRTIMP void __cdecl _wassert(const wchar_t *_Message,const wchar_t
*_File,unsigned _Line);
-_CRTIMP void __cdecl _assert (const char *_Message, const char *_File,
unsigned _Line);
+_CRTIMP void __cdecl __MINGW_ATTRIB_NORETURN _wassert(const wchar_t
*_Message,const wchar_t *_File,unsigned _Line);
+_CRTIMP void __cdecl __MINGW_ATTRIB_NORETURN _assert (const char *_Message,
const char *_File, unsigned _Line);
#ifdef __cplusplus
}
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
My use case is as follows.
I have a class template `S` with implicit inline functions in `lib.h`.
To improve compilation times, I want to explicitly instantiate common
specializations of this class template in `lib.cpp`.
In order to do so, I want to provide an explicit instantiation declaration
(`extern template`) of `S` in `lib.h`, and an explicit instantiation
definition of `S` in `lib.cpp`.
Now, I expect that every consumer linking against `lib` should be able to use
`S` without having to fully instantiate it.
The example I provided in my bug report cleanly compiles and links with
clang++, regardless of whether I have `__declspec(dllexport)` or not in the
declaration.
The example does not link when compiling `lib` with g++, if I have
`__declspec(dllexport)` in the declaration. It does link if I enable
`-Wl,--export-all-symbols` or if I remove the `__declspec(dllexport)`
altogether.
Putting the `__declspec(dllexport)` on the explicit template instantiation
definition results in a compiler warning telling me that it is ignored.
These results make me believe that we are experiencing a g++ bug related to
symbol exporting when targeting MinGW.
In my real project (see
https://github.com/vittorioromeo/SFML/tree/feature/remove_windows_h_dependency_for_gl_h,
Vector2 class), where I have the same use case, there's nothing I can do.
Regardless of whether I have `__declspec(dllexport)` or not, I get linker
errors on the explicit template instantation for `constexpr` member functions
such as `sf::Vector2::Vector2()`, which are declared and defined
as follows:
//
//
// Vector2.hpp (sfml-system library)
namespace sf
{
template
class Vector2
{
public:
SFML_SYSTEM_API constexpr Vector2();
// ...
};
}
extern template sf::Vector2::Vector2();
template
constexpr sf::Vector2::Vector2() = default;
//
//
// Vector2.cpp (sfml-system library)
template sf::Vector2::Vector2();
//
//
// GlContext.cpp (sfml-window library, depends on sfml-system)
// ...
std::make_unique(/* ... */, Vector2(1, 1));
// ^^^
// linker error here with g++
// ...
Removing `SFML_SYSTEM_API` or adding it to the explicit template definition has
no effect at all.
Removing the `extern template` results in another GCC bug, see
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109387).
Therefore I see no possible solution to my problem.
Hope this helps -- cheers,
Vittorio Romeo
https://vittorioromeo.com
From: LIU Hao
Sent: Monday, April 03, 2023 12:04 PM
To: mingw-w64-public@lists.sourceforge.net; Vittorio Romeo
Subject: Re: [Mingw-w64-public] GCC bugs with explicit template instantiation
and dllexport targeting MinGW
在 2023/4/3 16:55, Vittorio Romeo 写道:
> Hello everyone,
> Hope you are doing well.
>
> I've encountered and reported a bug related to explicit template
> instantiations and dllexport using the latest version of GCC on MinGW/MSYS2:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380
I don't think it's a bug. There are two issues in your testcase, one is that
extern template struct __declspec(dllexport) S;
is a declaration, and nothing can be exported from a declaration (you export
the definition instead).
The other is that `g()` is an implicit inline function. An inline function can
only be exported when
it is emitted as a non-inline copy, for example, when optimization is not
enabled, or when its
address is taken, or when it is virtual and the class has a non-pure non-inline
virtual function
(a.k.a. the key function) which instantiates its vtable.
--
Best regards,
LIU Hao
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
在 2023/4/3 16:55, Vittorio Romeo 写道: Hello everyone, Hope you are doing well. I've encountered and reported a bug related to explicit template instantiations and dllexport using the latest version of GCC on MinGW/MSYS2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 I don't think it's a bug. There are two issues in your testcase, one is that extern template struct __declspec(dllexport) S; is a declaration, and nothing can be exported from a declaration (you export the definition instead). The other is that `g()` is an implicit inline function. An inline function can only be exported when it is emitted as a non-inline copy, for example, when optimization is not enabled, or when its address is taken, or when it is virtual and the class has a non-pure non-inline virtual function (a.k.a. the key function) which instantiates its vtable. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
Hello everyone, Hope you are doing well. I've encountered and reported a bug related to explicit template instantiations and dllexport using the latest version of GCC on MinGW/MSYS2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 After looking at the GCC bug tracker, I've noticed quite a few related bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81855 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 Some of them are as old as 2017, which made me think that the GCC bug tracker might not be the best place to report MinGW-related issues. I've asked on the MSYS2 Discord and they've pointed me to this mailing list. Is this a good place to report these sort of MinGW-specific issues? It seems like they are largely ignored on the official GCC tracker. I would take a stab at these, but I have very poor knowledge and experience with the GCC codebase and linkers in general. Cheers, Vittorio Romeo https://vittorioromeo.com ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
