From: Erik de C. L. <ml...@me...> - 2009-09-17 02:55:23
|
Hi all, I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest I can find and running into problems compiling stuff like: printf ("Bad file length (%" PRId64 " should be %zd).\n", retval, sizeof (data_out)) ; The code works correctly for standard modern gccs on Linux systems and in the Ubuntu Linux -> mingw32 cross compiler. However, for the Linux -> mingw-win64 cross compiler I get: test.c:135:2: error: unknown conversion type character 'z' in format test.c:135:2: error: too many arguments for format In all of the above I am compiling with -std=gnu99. It would be really nice it this could be fixed. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-17 06:46:39
|
On Thu, Sep 17, 2009 at 5:55 AM, Erik de Castro Lopo <ml...@me...> wrote: > Hi all, > > I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest > I can find and running into problems compiling stuff like: > > printf ("Bad file length (%" PRId64 " should be %zd).\n", retval, sizeof (data_out)) ; > > The code works correctly for standard modern gccs on Linux systems > and in the Ubuntu Linux -> mingw32 cross compiler. > > However, for the Linux -> mingw-win64 cross compiler I get: > > test.c:135:2: error: unknown conversion type character 'z' in format > test.c:135:2: error: too many arguments for format > > In all of the above I am compiling with -std=gnu99. > > It would be really nice it this could be fixed. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ I'm not sure whether msvcrt supports the %z size_t conversion. You can, however, use the posix compliant mingw version. You can do it by either of these two ways: 1. You can compile your source with the __USE_MINGW_ANSI_STDIO macro defined as 1, adding -D__USE_MINGW_ANSI_STDIO=1 to your gcc command line. This way, all printf family of functions will be relaced by __mingw_printf, __mingw_fprintf, etc. 2. Or, you can explicitly use __mingw_printf at the specific places that is required. Hope this helps. -- Ozkan |
From: Erik de C. L. <ml...@me...> - 2009-09-17 22:14:56
|
Ozkan Sezer wrote: > I'm not sure whether msvcrt supports the %z size_t conversion. I'm pretty damn sure it doesn't :-). > You can, however, use the posix compliant mingw version. Its not POSIX, its ISO C99 :-). > You can do it by either of these two ways: > > 1. You can compile your source with the __USE_MINGW_ANSI_STDIO > macro defined as 1, adding -D__USE_MINGW_ANSI_STDIO=1 to your > gcc command line. This way, all printf family of functions will > be relaced by __mingw_printf, __mingw_fprintf, etc. I tried putting: #define __USE_MINGW_ANSI_STDIO 1 as the very first non-comment line of the file in questions and I still get: test_file_io.c:136: error: unknown conversion type character 'z' in format test_file_io.c:136: error: too many arguments for format If I replace that printf with __mingw_printf I get: test_file_io.c:136: error: implicit declaration of function '__mingw_printf' test_file_io.c:136: error: nested extern declaration of '__mingw_printf' Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-18 05:47:57
|
On Fri, Sep 18, 2009 at 1:14 AM, Erik de Castro Lopo <ml...@me...> wrote: > Ozkan Sezer wrote: > >> I'm not sure whether msvcrt supports the %z size_t conversion. > > I'm pretty damn sure it doesn't :-). > >> You can, however, use the posix compliant mingw version. > > Its not POSIX, its ISO C99 :-). > >> You can do it by either of these two ways: >> >> 1. You can compile your source with the __USE_MINGW_ANSI_STDIO >> macro defined as 1, adding -D__USE_MINGW_ANSI_STDIO=1 to your >> gcc command line. This way, all printf family of functions will >> be relaced by __mingw_printf, __mingw_fprintf, etc. > > I tried putting: > > #define __USE_MINGW_ANSI_STDIO 1 > > as the very first non-comment line of the file in questions and I still > get: > > test_file_io.c:136: error: unknown conversion type character 'z' in format > test_file_io.c:136: error: too many arguments for format > > If I replace that printf with __mingw_printf I get: > > test_file_io.c:136: error: implicit declaration of function '__mingw_printf' > test_file_io.c:136: error: nested extern declaration of '__mingw_printf' > > Erik Do you #include <stdio.h> ? If you do, then I'm baffled.. -- Ozkan |
From: Kai T. <kti...@go...> - 2009-09-18 05:59:24
|
Hello Erik, The issue is that the linux pre-build version of our toolchain is out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2, which doesn't provide this feature. Sadly we have at the moment a lack in machines for doing an automated build for linux (32-bit). The 64-bit we provide at the moment. So the only chance for you is at the moment doing bootstrap on linux by yourself. Simply to update headers isn't possible, as you need to update crt libraries, too. And well, your version of toolchain is pretty *old* and therefore doesn't contain many fixes in gcc and binutils. Regards, Kai |
From: Erik de C. L. <ml...@me...> - 2009-09-18 11:25:23
|
Kai Tietz wrote: > Hello Erik, > > The issue is that the linux pre-build version of our toolchain is > out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2, > which doesn't provide this feature. Ok, I've built an i686 Linux to win64 cross compiler using the script: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk Unfortunately I am now getting "undefined reference to `sin'" on code which compiles perfectly in gcc on Linux and with the Linux mingw32 cross compiler. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Erik de C. L. <ml...@me...> - 2009-09-18 11:35:16
|
Erik de Castro Lopo wrote: > Ok, I've built an i686 Linux to win64 cross compiler using the script: > > https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk > > Unfortunately I am now getting "undefined reference to `sin'" on code Sorry, please disregard that. My mistake. The compiler I've build does indeed seem to be working correctly. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: NightStrike <nig...@gm...> - 2009-09-18 14:47:12
|
On Fri, Sep 18, 2009 at 7:35 AM, Erik de Castro Lopo <ml...@me...> wrote: > Erik de Castro Lopo wrote: > >> Ok, I've built an i686 Linux to win64 cross compiler using the script: >> >> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk >> >> Unfortunately I am now getting "undefined reference to `sin'" on code > > Sorry, please disregard that. My mistake. > > The compiler I've build does indeed seem to be working correctly. > Any chance you'd like to contribute your builds? :) We are in need of a 32-bit linux machine to run as a build slave. |
From: Erik de C. L. <ml...@me...> - 2009-09-18 21:24:48
|
NightStrike wrote: > Any chance you'd like to contribute your builds? :) Sure. > We are in need of a 32-bit linux machine to run as a build slave. My machine is a laptop and is not always on, nor is it always connected to the net. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Erik de C. L. <ml...@me...> - 2009-09-18 22:12:36
|
Kai Tietz wrote: > The issue is that the linux pre-build version of our toolchain is > out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2, > which doesn't provide this feature. Ok, I've built an i686 Linux to win64 cross compiler using the script: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk The compiler says: Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 --prefix=/Testing/build/root --with-sysroot=/Testing/build/root --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.5.0 20090918 (experimental) (GCC) but I'm still getting: test.c:135:2: error: unknown conversion type character 'z' in format test.c:135:2: error: too many arguments for format Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-18 22:26:40
|
On Sat, Sep 19, 2009 at 1:12 AM, Erik de Castro Lopo <ml...@me...> wrote: > Using built-in specs. > Target: x86_64-w64-mingw32 > Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 > --prefix=/Testing/build/root --with-sysroot=/Testing/build/root > --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib > Thread model: win32 > gcc version 4.5.0 20090918 (experimental) (GCC) > > but I'm still getting: > > test.c:135:2: error: unknown conversion type character 'z' in format > test.c:135:2: error: too many arguments for format - Which svn revision of mingw-w64 headers and crt did you use in your toolchain ? - Contents of test.c (cat test.c), at least the relevant parts of it including the headers you include and macros you define that would affect things ? - Your exact command line for compiling test.c ? -- Ozkan |
From: Erik de C. L. <ml...@me...> - 2009-09-19 06:20:17
|
Ozkan Sezer wrote: > - Which svn revision of mingw-w64 headers and crt did you > use in your toolchain ? Same revision for both : Path: . URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk Repository Root: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64 Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1 Revision: 1375 Node Kind: directory Schedule: normal Last Changed Author: ktietz70 Last Changed Rev: 1375 Last Changed Date: 2009-09-18 17:08:14 +1000 (Fri, 18 Sep 2009) > - Contents of test.c (cat test.c), at least the relevant parts of it > including the headers you include and macros you define that > would affect things ? Well that test.c was a bit big, but this little snippet hits the same problem: #include <stdio.h> #include <inttypes.h> int main (void) { int64_t big_number = 1LL << 34 ; big_number *= 1027LL ; printf ("%-12" PRId64 " %zd\n", big_number, sizeof (big_number)) ; return 0 ; } > - Your exact command line for compiling test.c ? x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-19 06:36:06
|
On Sat, Sep 19, 2009 at 9:20 AM, Erik de Castro Lopo <ml...@me...> wrote: > Ozkan Sezer wrote: > >> - Which svn revision of mingw-w64 headers and crt did you >> use in your toolchain ? > > Same revision for both : > > Path: . > URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk > Repository Root: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64 > Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1 > Revision: 1375 > Node Kind: directory > Schedule: normal > Last Changed Author: ktietz70 > Last Changed Rev: 1375 > Last Changed Date: 2009-09-18 17:08:14 +1000 (Fri, 18 Sep 2009) > >> - Contents of test.c (cat test.c), at least the relevant parts of it >> including the headers you include and macros you define that >> would affect things ? > > Well that test.c was a bit big, but this little snippet hits the same > problem: > > #include <stdio.h> > #include <inttypes.h> > int main (void) > { int64_t big_number = 1LL << 34 ; > big_number *= 1027LL ; > printf ("%-12" PRId64 " %zd\n", big_number, sizeof (big_number)) ; > return 0 ; > } > >> - Your exact command line for compiling test.c ? > > x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test > > Erik Hmm, with my versions gcc-4.4.2 (svn r151768, patched but nothing that would affect this) and mingw-w64 r1375-r1378, I get: x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c test.c: In function 'main': test.c:6: warning: unknown conversion type character 'z' in format test.c:6: warning: too many arguments for format Notice that it's not an 'error' but a warning. How come you get an error? And if I add -D__USE_MINGW_ANSI_STDIO=1 to the command line, then I get no warnings at all. Did you try with -D__USE_MINGW_ANSI_STDIO=1 ? -- Ozkan |
From: Erik de C. L. <ml...@me...> - 2009-09-19 08:03:20
|
Ozkan Sezer wrote: > Hmm, with my versions gcc-4.4.2 (svn r151768, patched but > nothing that would affect this) and mingw-w64 r1375-r1378, > I get: > > x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c > test.c: In function 'main': > test.c:6: warning: unknown conversion type character 'z' in format > test.c:6: warning: too many arguments for format > > Notice that it's not an 'error' but a warning. How come you > get an error? Quite honestly, I think an unknown conversion type should be an error. The compiler is saying it doesn't understand the format conversion so it is almost certainly not going to do the right thing. > And if I add -D__USE_MINGW_ANSI_STDIO=1 > to the command line, then I get no warnings at all. Did you try > with -D__USE_MINGW_ANSI_STDIO=1 ? Yes, that fixes it. How come I have to use that for the w64 cross compiler but I don't need it for the w32 cross compiler? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-19 08:12:44
|
On Sat, Sep 19, 2009 at 11:02 AM, Erik de Castro Lopo <ml...@me...> wrote: > Ozkan Sezer wrote: > >> Hmm, with my versions gcc-4.4.2 (svn r151768, patched but >> nothing that would affect this) and mingw-w64 r1375-r1378, >> I get: >> >> x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c >> test.c: In function 'main': >> test.c:6: warning: unknown conversion type character 'z' in format >> test.c:6: warning: too many arguments for format >> >> Notice that it's not an 'error' but a warning. How come you >> get an error? > > Quite honestly, I think an unknown conversion type should be an > error. The compiler is saying it doesn't understand the format > conversion so it is almost certainly not going to do the right > thing. > >> And if I add -D__USE_MINGW_ANSI_STDIO=1 >> to the command line, then I get no warnings at all. Did you try >> with -D__USE_MINGW_ANSI_STDIO=1 ? > > Yes, that fixes it. How come I have to use that for the w64 cross > compiler but I don't need it for the w32 cross compiler? > You need it with both. (Although, if your w32 toolchain is a mingw.org toolchain and not ours, they may have automatically defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, should we do that?) > Erik -- Ozkan |
From: Erik de C. L. <ml...@me...> - 2009-09-19 10:14:38
|
Ozkan Sezer wrote: > You need it with both. (Although, if your w32 toolchain is > a mingw.org toolchain and not ours, they may have automatically > defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, > should we do that?) Yes, please! Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-19 10:35:51
|
On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo <ml...@me...> wrote: > Ozkan Sezer wrote: > >> You need it with both. (Although, if your w32 toolchain is >> a mingw.org toolchain and not ours, they may have automatically >> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, >> should we do that?) > > Yes, please! > > Cheers, > Erik > -- Hmm this is what the mingw.org guys do in their _mingw.h: #ifndef __USE_MINGW_ANSI_STDIO /* * If user didn't specify it explicitly... */ # if defined __STRICT_ANSI__ || defined _ISOC99_SOURCE \ || defined _POSIX_SOURCE || defined _POSIX_C_SOURCE \ || defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED \ || defined _GNU_SOURCE || defined _BSD_SOURCE \ || defined _SVID_SOURCE /* * but where any of these source code qualifiers are specified, * then assume ANSI I/O standards are preferred over Microsoft's... */ # define __USE_MINGW_ANSI_STDIO 1 # endif #endif (FWIW, we can also check for _POSIX for consistency with other parts of our headers, too.) Kai, we can add it to our _mingw.h, too. What do you think? Can this kind of thing cause any incompatibilities when a piece of software is compiled with -std=c99 or -std=gnu99 ? -- Ozkan |
From: Kai T. <kti...@go...> - 2009-09-19 10:38:19
|
Ok, add it to our _mingw.h file, too. We can then simplify our logic in our _mingw_printf_(push/pop).h headers, too, as we know that __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't it? Cheers, Kai 2009/9/19 Ozkan Sezer <se...@gm...>: > On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo > <ml...@me...> wrote: >> Ozkan Sezer wrote: >> >>> You need it with both. (Although, if your w32 toolchain is >>> a mingw.org toolchain and not ours, they may have automatically >>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, >>> should we do that?) >> >> Yes, please! >> >> Cheers, >> Erik >> -- > > Hmm this is what the mingw.org guys do in their _mingw.h: > > #ifndef __USE_MINGW_ANSI_STDIO > /* > * If user didn't specify it explicitly... > */ > # if defined __STRICT_ANSI__ || defined _ISOC99_SOURCE \ > || defined _POSIX_SOURCE || defined _POSIX_C_SOURCE \ > || defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED \ > || defined _GNU_SOURCE || defined _BSD_SOURCE \ > || defined _SVID_SOURCE > /* > * but where any of these source code qualifiers are specified, > * then assume ANSI I/O standards are preferred over Microsoft's... > */ > # define __USE_MINGW_ANSI_STDIO 1 > # endif > #endif > > (FWIW, we can also check for _POSIX for consistency with > other parts of our headers, too.) > > Kai, we can add it to our _mingw.h, too. What do you think? > Can this kind of thing cause any incompatibilities when a > piece of software is compiled with -std=c99 or -std=gnu99 ? > > -- > Ozkan > -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2009-09-19 10:41:58
|
On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz <kti...@go...> wrote: > Ok, add it to our _mingw.h file, too. We can then simplify our logic Will do. > in our _mingw_printf_(push/pop).h headers, too, as we know that > __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't > it? If you are referring to the rev. 1377 change, I wouldn't rely on it being definitely defined as 0 or 1. User may be buggy and would just do -D__USE_MINGW_ANSI_STDIO without an =0 or =1, would he not? > > Cheers, > Kai -- Ozkan > 2009/9/19 Ozkan Sezer <se...@gm...>: >> On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo >> <ml...@me...> wrote: >>> Ozkan Sezer wrote: >>> >>>> You need it with both. (Although, if your w32 toolchain is >>>> a mingw.org toolchain and not ours, they may have automatically >>>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, >>>> should we do that?) >>> >>> Yes, please! >>> >>> Cheers, >>> Erik >>> -- >> >> Hmm this is what the mingw.org guys do in their _mingw.h: >> >> #ifndef __USE_MINGW_ANSI_STDIO >> /* >> * If user didn't specify it explicitly... >> */ >> # if defined __STRICT_ANSI__ || defined _ISOC99_SOURCE \ >> || defined _POSIX_SOURCE || defined _POSIX_C_SOURCE \ >> || defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED \ >> || defined _GNU_SOURCE || defined _BSD_SOURCE \ >> || defined _SVID_SOURCE >> /* >> * but where any of these source code qualifiers are specified, >> * then assume ANSI I/O standards are preferred over Microsoft's... >> */ >> # define __USE_MINGW_ANSI_STDIO 1 >> # endif >> #endif >> >> (FWIW, we can also check for _POSIX for consistency with >> other parts of our headers, too.) >> >> Kai, we can add it to our _mingw.h, too. What do you think? >> Can this kind of thing cause any incompatibilities when a >> piece of software is compiled with -std=c99 or -std=gnu99 ? >> >> -- >> Ozkan |
From: Ozkan S. <se...@gm...> - 2009-09-19 10:57:58
|
OK, applied this as rev. 1395: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395 Please test. -- Ozkan On Sat, Sep 19, 2009 at 1:41 PM, Ozkan Sezer <se...@gm...> wrote: > On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz <kti...@go...> wrote: >> Ok, add it to our _mingw.h file, too. We can then simplify our logic > > Will do. > >> in our _mingw_printf_(push/pop).h headers, too, as we know that >> __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't >> it? > > If you are referring to the rev. 1377 change, I wouldn't rely > on it being definitely defined as 0 or 1. User may be buggy > and would just do -D__USE_MINGW_ANSI_STDIO without > an =0 or =1, would he not? > >> >> Cheers, >> Kai > > -- > Ozkan > >> 2009/9/19 Ozkan Sezer <se...@gm...>: >>> On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo >>> <ml...@me...> wrote: >>>> Ozkan Sezer wrote: >>>> >>>>> You need it with both. (Although, if your w32 toolchain is >>>>> a mingw.org toolchain and not ours, they may have automatically >>>>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai, >>>>> should we do that?) >>>> >>>> Yes, please! >>>> >>>> Cheers, >>>> Erik >>>> -- >>> >>> Hmm this is what the mingw.org guys do in their _mingw.h: >>> >>> #ifndef __USE_MINGW_ANSI_STDIO >>> /* >>> * If user didn't specify it explicitly... >>> */ >>> # if defined __STRICT_ANSI__ || defined _ISOC99_SOURCE \ >>> || defined _POSIX_SOURCE || defined _POSIX_C_SOURCE \ >>> || defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED \ >>> || defined _GNU_SOURCE || defined _BSD_SOURCE \ >>> || defined _SVID_SOURCE >>> /* >>> * but where any of these source code qualifiers are specified, >>> * then assume ANSI I/O standards are preferred over Microsoft's... >>> */ >>> # define __USE_MINGW_ANSI_STDIO 1 >>> # endif >>> #endif >>> >>> (FWIW, we can also check for _POSIX for consistency with >>> other parts of our headers, too.) >>> >>> Kai, we can add it to our _mingw.h, too. What do you think? >>> Can this kind of thing cause any incompatibilities when a >>> piece of software is compiled with -std=c99 or -std=gnu99 ? >>> >>> -- >>> Ozkan > |
From: Erik de C. L. <ml...@me...> - 2009-09-19 22:09:17
|
Ozkan Sezer wrote: > OK, applied this as rev. 1395: > http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395 > Please test. Real close! I get the proper C99 behaviour if I compile with: x86_64-w64-mingw32-gcc -Wall -std=c99 test.c -o test but with this: x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test I still get the same error. It would be nice if this could be fixed for gnu99 as well. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-19 23:25:08
|
On Sun, Sep 20, 2009 at 1:08 AM, Erik de Castro Lopo <ml...@me...> wrote: > Ozkan Sezer wrote: > >> OK, applied this as rev. 1395: >> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395 >> Please test. > > Real close! > > I get the proper C99 behaviour if I compile with: > > x86_64-w64-mingw32-gcc -Wall -std=c99 test.c -o test > > but with this: > > x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test > > I still get the same error. It would be nice if this could be fixed for > gnu99 as well. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ That is because with -std=c99, gcc predefines __STRICT_ANSI_, but with -std=gnu99 it does not, because gnu99 is not _strictly_ ansi and includes gnu extensions. The idea behind our commit rev. 1395 is trying to catch ith implications of user's need of ansi i/o, and in my opinion -std=gnu99 may not be in that category. Please define __USE_MINGW_ANSI_STDIO=1 for it. Enabling the __mingw_printf family for both c99 and gnu99 mode is actually easy, I would only add a __STDC_VERSION__ >= 199901L preprocessor check, but as I said I think it might not be right. Kai, what do you think? A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org compiler for your w32 builds? I think the warning may be a gcc-4.4+ thing and not actually a mingw-w64 issue, but I don't know for sure. -- Ozkan |
From: Erik de C. L. <ml...@me...> - 2009-09-19 23:56:00
|
Please note, I am subscribed to the list. No need to CC me on reply. Ozkan Sezer wrote: > A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org > compiler for your w32 builds? I think the warning may be a gcc-4.4+ > thing and not actually a mingw-w64 issue, but I don't know for sure. Now that I've checked, it seems a little more complicated than I first thought. The mingw32 compiler that I'm using is the one from the Ubuntu 9.04 mingw32 package. It reports its version as: gcc version 4.2.1-sjlj (mingw32-2) This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well as the other C99 format string stuff. The mingw32 package on Debian Sid is: gcc version 4.4.1 (GCC) and it too gives a warning on both c99 and gnu99. For this compiler, not even -D__USE_MINGW_ANSI_STDIO=1 can fix it. Me, I'd just like to compile the one piece of source code on as many systems as possible without hacking it to bits with #ifdefs. I'd also like, where possible, to get the compiler using apt-get, instead of compling it myself. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ |
From: Ozkan S. <se...@gm...> - 2009-09-20 08:30:23
|
On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo <ml...@me...> wrote: > > Please note, I am subscribed to the list. No need to CC me on reply. > > Ozkan Sezer wrote: > >> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org >> compiler for your w32 builds? I think the warning may be a gcc-4.4+ >> thing and not actually a mingw-w64 issue, but I don't know for sure. > > Now that I've checked, it seems a little more complicated than I first > thought. > > The mingw32 compiler that I'm using is the one from the Ubuntu 9.04 > mingw32 package. It reports its version as: > > gcc version 4.2.1-sjlj (mingw32-2) > > This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well > as the other C99 format string stuff. > OK, looked at the mingw.org phovided gcc4.2.1-2 source and they add windows specific format specifiers like %I32 in gcc/config/i386/mingw32.h but with a note like: /* MSVCRT supports additional length specifiers for "printf". (In fact, it does not support some of the C99 specifiers, like "ll". However, we do not presently have a mechanism for disabling a specifier.) */ 4.4 was the version that ms-printf format support officially went into gcc along with mechanisms catching what is OK and what is not. A note out of curiosity: Does your versions compiled by gcc < 4.4 of mingw.org give correct output ? > The mingw32 package on Debian Sid is: > > gcc version 4.4.1 (GCC) > > and it too gives a warning on both c99 and gnu99. For this compiler, > not even -D__USE_MINGW_ANSI_STDIO=1 can fix it. > > Me, I'd just like to compile the one piece of source code on as many systems > as possible without hacking it to bits with #ifdefs. I'd also like, > where possible, to get the compiler using apt-get, instead of compling it > myself. > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > -- Ozkan |
From: Kai T. <kti...@go...> - 2009-09-20 08:45:10
|
2009/9/20 Ozkan Sezer <se...@gm...>: > On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo > <ml...@me...> wrote: >> >> Please note, I am subscribed to the list. No need to CC me on reply. >> >> Ozkan Sezer wrote: >> >>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org >>> compiler for your w32 builds? I think the warning may be a gcc-4.4+ >>> thing and not actually a mingw-w64 issue, but I don't know for sure. >> >> Now that I've checked, it seems a little more complicated than I first >> thought. >> >> The mingw32 compiler that I'm using is the one from the Ubuntu 9.04 >> mingw32 package. It reports its version as: >> >> gcc version 4.2.1-sjlj (mingw32-2) >> >> This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well >> as the other C99 format string stuff. >> > > OK, looked at the mingw.org phovided gcc4.2.1-2 source > and they add windows specific format specifiers like %I32 > in gcc/config/i386/mingw32.h but with a note like: > > /* MSVCRT supports additional length specifiers for "printf". (In > fact, it does not support some of the C99 specifiers, like > "ll". However, we do not presently have a mechanism for disabling > a specifier.) */ > > 4.4 was the version that ms-printf format support officially > went into gcc along with mechanisms catching what is OK > and what is not. > > A note out of curiosity: Does your versions compiled by > gcc < 4.4 of mingw.org give correct output ? > >> The mingw32 package on Debian Sid is: >> >> gcc version 4.4.1 (GCC) >> >> and it too gives a warning on both c99 and gnu99. For this compiler, >> not even -D__USE_MINGW_ANSI_STDIO=1 can fix it. >> >> Me, I'd just like to compile the one piece of source code on as many systems >> as possible without hacking it to bits with #ifdefs. I'd also like, >> where possible, to get the compiler using apt-get, instead of compling it >> myself. >> >> Erik >> -- >> ---------------------------------------------------------------------- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> > > -- > Ozkan > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > As mingw.org doesn't use any printf formatter rules for their redirected functions (which is IMHO a bug), they don't get warnings for anything passed into this functions. IMHO as more as I think about this feature, it should be turned on on user demand by defining __USE_MINGW_ANSI_STDIO explicit. To turn it on for some cX9 standards, or for __GNU_SOURCE, etc is misleading and a mis-concept. We can automatically turn it on, if _POSIX is defined, but the rest is just buggy. Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |