Re: [Mingw-w64-public] Build error libgomp
在 2020/12/11 18:26, Christer Solskogen 写道: > While compiling the mingw-w64 cross compiler I got this with gcc-10.2.0: > > (... snip ...) > > Is this a gcc problem or mingw-w64 problem? Or perhaps "my" problem if I've > configured something > wrongly. > mingw-w64 is from the latest v8.x branch. > This error is caused by the new behavior of stdio format specifiers. Now when compiling with at least C99 or C++11 standard, mingw-w64 stdio functions are enabled by default (unless suppressed by defining `__USE_MINGW_ANSI_STDIO` to zero) so `PRId64` now expands to `lld` instead of the old MS-specified `I64d`. libgomp has the `printf` format attribute so its diagnostic functions do not recognize standard specifiers and cause errors. A patch for GCC 10 is available here [1]. [1] https://github.com/msys2/MINGW-packages-dev/blob/68b5075842e2d13191f31a8619dfb262d73beb6a/mingw-w64-gcc-git/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ 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 01/14] update windows.security.cryptography.h
On 2020-12-11 1:02, Jacek Caban wrote: Hi Steve, Hi Jacek, It's great to see work on getting those IDLs to be in a form that we can regenerate them again. Thanks! Yes. For now I call widl manually because it seems that many of the IDLs currently don't build. Should we fix those as well ? Apart from the winrt ones they don't use a namespace so should produce more of less the same thing as before. There is recently an active (well, except for Wine code freeze) work on Wine side to improve support for winrt widl mode by Rémi Bernon. Great news. Hopefully widl will be able to properly support all those new constructs. I recently updated widl in mingw-w64 repo to a more recent upstream version and it already generates those headers differently. I think this patch will not work with enum handling changes. I'll have a look. I also noticed the wine code has even more changes. But IMO the IDLs and the headers in the mingw64 tree should match the widl in the same tree, IMO. That's why updating widl should also be paired with running the IDLs through it again. And why it's important the current tree already builds properly. Also, I'm not convinced that we want more new interfaces that require hacking around widl shortcomings. It would be great to have those fixed in widl instead. I'd say we should get changes that allow us to regenerate existing declarations with the new widl, but coordinate with widl on new additions. After having to hack my way through the IDLs files I agree. Alhough it seems there are some lexer in widl that I may not be capabale to update. But that would definitely be a good goal. On the other hand, widl seems to be mostly a wine thing and there is no IDL with namespaces, events, templates, etc. Would changes that have no use in wine be accepted anyway ? One thing that should be easy to support is eventadd/eventremove support. It's just adding a prefix like propget/propput. Templates are trickier because each variant has its own UUID which is not defined in the MS doc nor in their IDL files. Luckily just by implementing them it's possible to get the proper UUID when the code requests it in QueryInterface(). That means each variant needs to be explictely declared and given its UUID. The generated names in MS headers are quite different as well as they include the number of elements in the template and the full namespace for each element in the template. Proper templating in widl should produce similar code so code compiling with MSVC can also compile with mingw64. I will have a look at that but make no promise. What about this particular patch that changes the generated code, making previous code that compiled with mingw64 unusable. It's my understanding that this file (and pretty much all the winrt) was added for VLC so maybe noone else is using it ? The code was not compatible with MSVC headers but after this patch it should be. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Build error libgomp
While compiling the mingw-w64 cross compiler I got this with gcc-10.2.0:
/home/builder/gcc/libgomp/target.c: In function ‘gomp_map_vars_internal’:
/home/builder/gcc/libgomp/target.c:1228:21: error: unknown conversion
type character ‘l’ in format [-Werror=format=]
1228 | gomp_fatal ("present clause: !acc_is_present (%p, "
| ^~~
In file included from /home/builder/gcc/libgomp/target.c:36:
/tmp/cross-mingw-w64/x86_64-w64-mingw32/include/inttypes.h:36:18: note:
format string is defined here
36 | #define PRIu64 "llu"
| ^
/home/builder/gcc/libgomp/target.c:1228:21: error: unknown conversion
type character ‘l’ in format [-Werror=format=]
1228 | gomp_fatal ("present clause: !acc_is_present (%p, "
| ^~~
In file included from /home/builder/gcc/libgomp/target.c:36:
/tmp/cross-mingw-w64/x86_64-w64-mingw32/include/inttypes.h:37:18: note:
format string is defined here
37 | #define PRIx64 "llx"
| ^
/home/builder/gcc/libgomp/target.c:1228:21: error: too many arguments
for format [-Werror=format-extra-args]
1228 | gomp_fatal ("present clause: !acc_is_present (%p, "
| ^~~
cc1: all warnings being treated as errors
gmake[4]: *** [Makefile:827: target.lo] Error 1
gmake[4]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[3]: *** [Makefile:1057: all-recursive] Error 1
gmake[3]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[2]: *** [Makefile:648: all] Error 2
gmake[2]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[1]: *** [Makefile:15784: all-target-libgomp] Error 2
gmake[1]: Leaving directory '/tmp/build/gcc.x86_64-w64-mingw32'
gmake: *** [Makefile:966: all] Error 2
Is this a gcc problem or mingw-w64 problem? Or perhaps "my" problem if
I've configured something wrongly.
mingw-w64 is from the latest v8.x branch.
--
chs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
