Bug 97484 - typedef conflict for "byte" in GCC11 for MinGW-w64
Summary: typedef conflict for "byte" in GCC11 for MinGW-w64
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-19 06:27 UTC by Brecht Sanders
Modified: 2023-03-14 21:13 UTC (History)
2 users (show)

See Also:
Host:
Target: x86_64-MinGW-W64
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brecht Sanders 2020-10-19 06:27:46 UTC
I just built GCC11 snapshot 20201011 for the MinGW-w64 platform and noticed that some things won't build with it because "byte" now has conflicting definitions.
Windows seems to already define this in rpcndr.h, which is included from windows.h.
But it's also defined in C++' cpp_type_traits.

The errors below are from an attempt to compile Ninja with GCC11 snapshot 20201011.

These issues were not present with GCC 11 or lower.

In file included from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\wtypes.h:8,
                 from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\winscard.h:10,
                 from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\windows.h:97,
                 from .\src\disk_interface.cc:27:
d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\rpcndr.h:64:11: error: reference to 'byte' is ambiguous
   64 |   typedef byte cs_byte;
      |           ^~~~
In file included from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\stl_algobase.h:61,
                 from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\stl_tree.h:63,
                 from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\map:60,
                 from .\src\disk_interface.h:18,
                 from .\src\disk_interface.cc:15:
d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\cpp_type_traits.h:404:30: note: candidates are: 'enum class std::byte'
  404 |   enum class byte : unsigned char;
      |                              ^~~~
In file included from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\wtypes.h:8,
                 from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\winscard.h:10,
                 from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\windows.h:97,
                 from .\src\disk_interface.cc:27:
d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\rpcndr.h:63:25: note:                 'typedef unsigned char byte'
   63 |   typedef unsigned char byte;
      |                         ^~~~
Comment 1 Richard Biener 2020-10-19 08:04:01 UTC
I guess there needs to be a workaround on the windows side?
Comment 2 Jakub Jelinek 2020-10-19 08:26:42 UTC
Does Ninja use
using namespace std;
before including standard headers, or does some mingw header use that?
Comment 3 Brecht Sanders 2020-10-19 09:39:36 UTC
MinGW is pure C, so it doesn't use: using namespace std;
But I do see Ninja doing this before including windows.h.
However GCC 10 and older have no issue with this.
What changed in GCC 11 to cause the issue?
Comment 4 Jakub Jelinek 2020-10-19 09:45:36 UTC
(In reply to Brecht Sanders from comment #3)
> MinGW is pure C, so it doesn't use: using namespace std;
> But I do see Ninja doing this before including windows.h.

Then it is Ninja that needs to be fixed.  One can use using namespace std;,
but better only after including all headers one has no control over, because it significantly affects name lookup.

> However GCC 10 and older have no issue with this.
> What changed in GCC 11 to cause the issue?

GCC 11 defaults to -std=c++17, while GCC 10 defaulted to -std=c++14.
I bet it won't compile even with GCC 10 if you use -std=c++17.
Comment 5 Brecht Sanders 2020-10-19 10:09:50 UTC
Yes, you're right, when setting CXXFLAGS="-std=c++17" and building with GCC 10 Ninja also fails to build.

I have opened a ticket with Ninja for this, see: https://github.com/ninja-build/ninja/issues/1861
Comment 6 Abderraouf Bousri 2023-03-14 21:13:45 UTC
yes you are right, it was generating that error when i tried to compile with those configurations :

CMAKE_CXX_STANDARD 17   and g++ (8.0, 9.0, 10.0 and 12), also i tried with visual studio and Ninja.

i changed the flag to c++14, now it works (with g++ 8.0) :
    set(CMAKE_CXX_STANDARD 14)  #in your CMakeLists.txt
run this cmake command on windows : 
    cmake -G "MinGW Makefiles" -D CMAKE_CXX_COMPILER=g++ ..