Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11374 closed defect (fixed)

Client code with -std=c++0x (__STRICT_ANSI__) fails to compile

Reported by: Trigve Owned by:
Priority: normal Milestone:
Component: base Version: stable-latest
Keywords: c++0x ansi Cc:
Blocked By: Blocking:
Patch: yes

Description

Client code that use -std=c++0x compiler option with mingw failed to compile, because STRICT_ANSI is defined.

Attachments (1)

std_c00x_client.patch download (2.9 KB) - added by Trigve 4 years ago.

Download all attachments as: .zip

Change History (5)

Changed 4 years ago by Trigve

comment:1 Changed 4 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [62518]) Fix wx headers compilation in mingw32 strict ANSI mode.

Add checks for !defined(STRICT_ANSI) when checking for various common but
non-standard CRT extensions.

This allows compiling programs using wx with g++ -std=c++[0x] option (notice
that compiling wx itself using it still doesn't work).

Closes #11374.

comment:2 Changed 4 years ago by VZ

(In [63164]) Only disable use of non-ANSI functions in strict ANSI mode under Windows.

The changes of r62518 fixed compilation of wx headers in g++ strict ANSI mode
(enabled by th use of -ansi or -std=c++{98,0x} options) with mingw32 but
broke it when using g++ in ANSI mode under Unix. The problems arose at least
due to redeclaration of isascii() with different exception specifier and due
to the lack of wxCRT_StrdupA() definition in the library.

Fix this by simply not disabling the use of non-ANSI functions such as
isascii() and strdup() under Unix as they are still available in the headers
by default because of _GNU_SOURCE predefined by g++.

Notice that if _GNU_SOURCE is explicitly undefined, compilation would probably
still be broken. To fix this we might check whether USE_SVID is defined
under Linux. Unfortunately doing tests in configure is not an answer as
wxWidgets might not be compiled with the same -std option as the programs
using it, so there is no obviously correct way to fix this.

See #11374.

comment:3 follow-up: Changed 4 years ago by vadz

I've tried to retest this after my latest changes but I have the impression that -ansi is broken with MinGW 4.4 that I have, trying to use it results in

In file included from w:\dev\mingw\4.4.0\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/postypes.h:42,
                 from w:\dev\mingw\4.4.0\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/char_traits.h:42,
                 from w:\dev\mingw\4.4.0\bin\../lib/gcc/mingw32/4.4.0/include/c++/string:42,
                 from ../../include/wx/stringimpl.h:73,
                 from ../../include/wx/unichar.h:16,
                 from ../../include/wx/strvararg.h:23,
                 from ../../include/wx/string.h:53,
                 from ../../include/wx/memory.h:16,
                 from ../../include/wx/object.h:20,
                 from ../../include/wx/wx.h:16,
                 from minimal.cpp:30:
w:\dev\mingw\4.4.0\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:159: error: '::swprintf' has not been declared
w:\dev\mingw\4.4.0\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:166: error: '::vswprintf' has not been declared

and there doesn't seem to be anything we can do about this...

comment:4 in reply to: ↑ 3 Changed 4 years ago by Trigve

  • Keywords c++0x ansi added

Replying to vadz:

I've tried to retest this after my latest changes but I have the impression that -ansi is broken with MinGW 4.4 that I have, trying to use it results in
...
and there doesn't seem to be anything we can do about this...

This ticket was originally opened because I wanted to test some c++0x (STRICT_ANSI implication) features with wx. But I was not aware of option -std=gnu++0x. I think option -std=gnu++0x should be used instead of -std=c++0x.

Anyway you could try TDM mingw 4.4.1-2

Note: See TracTickets for help on using tickets.