Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on multi-arch code fails on mingw 64bits

Post

multi-arch code fails on mingw 64bits

+3
−0

I have a C/++ codebase that compiles in Windows x86_64 targeting x86 using the mingw32 32-bit shell of the MSYS64 project.

(It also compiles fine on linux x86/x86_64 and android's 4 archs.)

However, if i change to running it in the 64-bit shell, i get this error when compiling:

C:/msys64/mingw64/include/stdlib.h:303:23: error: expected ',' or '...' before numeric constant
  303 |   int __cdecl abs(int _X);
      |                       ^~

the code block being:

#ifndef _CRT_ABS_DEFINED
#define _CRT_ABS_DEFINED
  int __cdecl abs(int _X);
  long __cdecl labs(long _X);
#endif

I believe this file comes from mingw-w64-x86_64-headers-git from the mingw-w64-x86_64-toolchain metapackage.

I find it odd that this would be a MinGW error but what's triggering this on my code is a simple #include <string>.

Among others, my Makefile has -lmingw64, what am i missing?


Following @Lundin's comment i ended up reinstalling msys2/ucrt64 only, in another vm, and try again. Did clear that, but now i hit

C:/msys64/ucrt64/include/c++/14.2.0/limits:2100:30: error: unable to find numeric literal operator 'operator""Q'
 2100 |         return __extension__ 0x1.0p-16382Q;
      |                              ^~~~~~~~~~~~~

the lines being

#ifdef __STRICT_ANSI__
        // 0x1.0p-30 * 0x1.0p-16352
        return double(9.3132257461547852e-10) * _S_1pm16352();
#else
        return __extension__ 0x1.0p-16382Q;
#endif

I've tried with -D__STRICT_ANSI__ but it hits the same line (after a make clean), so somewhere in the includes it's being undefined.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

What happens if you remove the Q? Or try CXXFLAGS += -std=c++17 -fno-fast-math Are you using gc... (2 comments)
Reserved identifiers (2 comments)
Reserved identifiers
Lundin‭ wrote 3 months ago

_X is an identifier reserved for the library, so for whatever the reason, the compiler doesn't think you are compiling libraries but application code. I suppose this can happen if you mix different library implementations together. There are for example different flavours of Mingw64 CRT: the older MSVC CRT which also struggles with C standard compliance, and the newer UCRT which I believe was introduced from Windows 10 and beyond(?). You can download linked Mingw executables from here: https://winlibs.com/. Try using another CRT I suppose.

JohnRando‭ wrote about 2 months ago

I ended up installing the x86_64 toolchain in another place and the conflicts stopped.