From: Jonathan S. <js-...@we...> - 2008-12-14 14:27:08
Attachments:
signature.asc
|
Hello! I need asprintf in my project, which is, however missing. This is why I wanted to implement it using vsnprintf - calling it with buffer NULL and size 0 should return the size required for the string, but on Windows, it just always returns -1. I found _vsncprintf in the Microsoft documentation, which should return the size required. However, the MinGW ld always complains it's undefined, even if I specify -lmsvcr70 or -lmsvcr90 - it just doesn't care. I verified that it's defined in the .a file, and it is. I even extracted the .o which contains it from the .a, and then it wasn't undefined anymore, but I got other undefined symbols. I got objc running now, but I need static linking for this (see my other mail). I somehow got the impression now that the MinGW ld is broken somehow, as it doesn't include all the required stuff on dynamic linking and on static linking doesn't find defined symbols?! I tried manually linking the .exe like this: asgard:OFObject$ mingw32-gcc -o ofobject.exe OFObject.o -L../../src -lobjfw -lobjc -msvcr70 ../../src/libobjfw.a(asprintf.o): In function `asprintf': /home/js/devel/libobjfw/src/asprintf.c:52: undefined reference to `__vscprintf' collect2: ld returned 1 exit status Versions: asgard:~$ prt-get current mingw32-binutils 2.19-1 asgard:~$ prt-get current mingw32-gcc 4.3.0-20080502-1 asgard:~$ prt-get current mingw32-api 3.12-1 asgard:~$ prt-get current mingw32-runtime 3.15.1-1 Any help is very appreciated! -- Jonathan |
From: Jonathan S. <js-...@we...> - 2008-12-14 14:34:40
Attachments:
signature.asc
|
Jonathan Schleifer <js-...@we...> wrote: > […] Uhm, when I wrote _vsncprintf, I meant of course _vscprinf. In the source, it's correct (see the output at the end of the mail). -- Jonathan |
From: Keith M. <kei...@us...> - 2008-12-14 15:53:29
|
On Sunday 14 December 2008 14:26:53 Jonathan Schleifer wrote: > I need asprintf in my project, which is, however missing. This is > why I wanted to implement it using vsnprintf - calling it with > buffer NULL and size 0 should return the size required for the > string, What version of mingwrt are you using? AFAIK, MinGW's vsnprintf() has done exactly this, for at least a couple of years now; 3.15.1 uses a completely new implementation, which definitely does this! > but on Windows, it just always returns -1. That's the behaviour of Microsoft's _vsnprintf() implementation; (note the initial underscore). > I somehow got the impression now that the MinGW ld is broken > somehow, as it doesn't include all the required stuff on dynamic > linking and on static linking doesn't find defined symbols?! Strange then, that no one else is reporting similar failures. > I tried manually linking the .exe like this: > asgard:OFObject$ mingw32-gcc -o ofobject.exe OFObject.o -L../../src > -lobjfw -lobjc -msvcr70 ../../src/libobjfw.a(asprintf.o): In > function > `asprintf': /home/js/devel/libobjfw/src/asprintf.c:52: undefined > reference to `__vscprintf' collect2: ld returned 1 exit status That looks rather garbled; I suspect it it should look like: asgard:OFObject$ mingw32-gcc -o ofobject.exe OFObject.o \ -L../../src -lobjfw -lobjc -msvcr70 ../../src/libobjfw.a(asprintf.o): In function `asprintf': /home/js/devel/libobjfw/src/asprintf.c:52: undefined reference to `__vscprintf' collect2: ld returned 1 exit status If so, then what is option `-msvcr70' supposed to do? I'm surprised it didn't elicit a complaint about an invalid option; it certainly isn't the way to substitute libmsvcr70.a for the default libmsvcrt.a, so you are still linking against this default, which doesn't provide the symbol you are trying to resolve. To change to an alternative MSVCRT version requires modification of the GCC specs file; for guidance, please see: http://www.mingw.org/node/25 (and, in particular): http://www.mingw.org/node/25#comment-106 If you want further follow-up, please provide a minimal self-contained test case, to demonstrate the problem. Regards, Keith. |
From: Jonathan S. <js-...@we...> - 2008-12-14 16:07:20
Attachments:
signature.asc
|
Keith Marshall <kei...@us...> wrote: > On Sunday 14 December 2008 14:26:53 Jonathan Schleifer wrote: > > I need asprintf in my project, which is, however missing. This is > > why I wanted to implement it using vsnprintf - calling it with > > buffer NULL and size 0 should return the size required for the > > string, > > What version of mingwrt are you using? AFAIK, MinGW's vsnprintf() > has done exactly this, for at least a couple of years now; 3.15.1 > uses a completely new implementation, which definitely does this! As written below, it's 3.15.1. > > but on Windows, it just always returns -1. > > That's the behaviour of Microsoft's _vsnprintf() implementation; > (note the initial underscore). I just did #include <stdio.h> and used vsnprintf(). > > I somehow got the impression now that the MinGW ld is broken > > somehow, as it doesn't include all the required stuff on dynamic > > linking and on static linking doesn't find defined symbols?! > > Strange then, that no one else is reporting similar failures. Well, haven't seen so many objc Win32 apps yet, that might be the reason. See the other mail, it seems it doesn't include the interfaces of classes. > > I tried manually linking the .exe like this: > > asgard:OFObject$ mingw32-gcc -o ofobject.exe OFObject.o -L../../src > > -lobjfw -lobjc -msvcr70 ../../src/libobjfw.a(asprintf.o): In > > function > > `asprintf': /home/js/devel/libobjfw/src/asprintf.c:52: undefined > > reference to `__vscprintf' collect2: ld returned 1 exit status > > That looks rather garbled; I suspect it it should look like: > asgard:OFObject$ mingw32-gcc -o ofobject.exe OFObject.o \ > -L../../src -lobjfw -lobjc -msvcr70 > ../../src/libobjfw.a(asprintf.o): In function > `asprintf': /home/js/devel/libobjfw/src/asprintf.c:52: undefined > reference to `__vscprintf' > collect2: ld returned 1 exit status > > If so, then what is option `-msvcr70' supposed to do? I'm surprised > it didn't elicit a complaint about an invalid option; it certainly > isn't the way to substitute libmsvcr70.a for the default libmsvcrt.a, > so you are still linking against this default, which doesn't provide > the symbol you are trying to resolve. It seems I accidentallly killed the -l from msvcrt70 when I removed other useless stuff from the output so it doesn't get unreadable. In fact, I used -lmsvcrt70. > To change to an alternative MSVCRT version requires modification of > the GCC specs file; for guidance, please see: > http://www.mingw.org/node/25 > > (and, in particular): > http://www.mingw.org/node/25#comment-106 > > If you want further follow-up, please provide a minimal > self-contained test case, to demonstrate the problem. I will read those and reply again. Thanks a lot for your help! -- Jonathan |
From: Jonathan S. <js-...@we...> - 2008-12-14 16:32:02
Attachments:
signature.asc
|
Ok, that looks like it's not possible to automate that. I'm currently writing a framework for the objective C language and trying to port it to win32. I need asprintf in it, so I tried implementing it like this: https://webkeks.org/hg/libobjfw/file/e404f1076444/src/asprintf.c#l1 The problem is this line: if ((size = vsnprintf(NULL, 0, fmt, args)) < 0) Which always sets size to -1 and thus fails. I tried using _vscprintf instead, which led to the linking error I quoted before. For the dynamic linking problem, see this message: http://sourceforge.net/mailarchive/forum.php?thread_name=20081213211741.42275a83%40webkeks.org&forum_name=mingw-users -- Jonathan |
From: Keith M. <kei...@us...> - 2008-12-14 19:34:37
|
On Sunday 14 December 2008 16:31:48 Jonathan Schleifer wrote: > The problem is this line: > > if ((size = vsnprintf(NULL, 0, fmt, args)) < 0) > > Which always sets size to -1 and thus fails. If you don't show us a minimal self-contained, (and complete), test case, how can you expect us to see what you might be doing wrong? $ cat <<EOF > demo.c #include <stdio.h> int main() { char *argv[] = { "A string", NULL }; int l = vsnprintf( NULL, 0, "%s", (void *)(argv) ); printf( "Required size = %d\n", l ); return 0; } EOF $ mingw32-gcc -o demo.exe demo.c $ wine demo.exe Required size = 8 works for me, with GCC-3.4.5 and mingwrt-3.15.1. Regards, Keith |
From: Jonathan S. <js-...@we...> - 2008-12-14 19:38:11
Attachments:
PGP.sig
|
Am 14.12.2008 um 20:34 schrieb Keith Marshall: > On Sunday 14 December 2008 16:31:48 Jonathan Schleifer wrote: >> The problem is this line: >> >> if ((size = vsnprintf(NULL, 0, fmt, args)) < 0) >> >> Which always sets size to -1 and thus fails. > > If you don't show us a minimal self-contained, (and complete), test > case, how can you expect us to see what you might be doing wrong? The test case is the asprintf.c which I linked. Try it with any format string, it will always return -1. > $ cat <<EOF > demo.c > #include <stdio.h> > > int main() > { > char *argv[] = { "A string", NULL }; > int l = vsnprintf( NULL, 0, "%s", (void *)(argv) ); > printf( "Required size = %d\n", l ); > return 0; > } > EOF > > $ mingw32-gcc -o demo.exe demo.c > > $ wine demo.exe > Required size = 8 > > works for me, with GCC-3.4.5 and mingwrt-3.15.1. That indeed works. I'll try to find out why yours does while mine doesn't. -- Jonathan |
From: Keith M. <kei...@us...> - 2008-12-14 23:29:24
|
On Sunday 14 December 2008 19:38:40 Jonathan Schleifer wrote: > > If you don't show us a minimal self-contained, (and complete), > > test case, how can you expect us to see what you might be doing > > wrong? > > The test case is the asprintf.c which I linked. But, you didn't put it IN THE MAIL; there are few who will take the trouble to chase web links, to assist you. The point about a minimal test case is that it should be sufficient to illustrate the problem, but small enough to post inline, within a mail message; if you need to post a link, then you likely haven't reduced the problem enough. Note that asprintf() and vasprintf() are required by neither the ISO C Standard, nor by POSIX; GNU and BSD provide them as extras. Having said that, FWIW, here is how I might implement them: $ cat <<EOF > asprintf.c #include <stdio.h> #include <stdarg.h> #include <stdlib.h> int asprintf( char **, char *, ... ); int vasprintf( char **, char *, va_list ); int vasprintf( char **sptr, char *fmt, va_list argv ) { int wanted = vsnprintf( *sptr = NULL, 0, fmt, argv ); if( (wanted > 0) && ((*sptr = malloc( 1 + wanted )) != NULL) ) return vsprintf( *sptr, fmt, argv ); return wanted; } int asprintf( char **sptr, char *fmt, ... ) { int retval; va_list argv; va_start( argv, fmt ); retval = vasprintf( sptr, fmt, argv ); va_end( argv ); return retval; } int main() { char *retbuf; int len = asprintf( &retbuf, "%s", "An allocated string." ); printf( "Allocated %d + 1 bytes for string '%s'\n", len, retbuf ); free( retbuf ); return 0; } EOF $ mingw32-gcc -o asprintf.exe asprintf.c $ wine asprintf.exe Allocated 20 + 1 bytes for string 'An allocated string.' Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-12-15 02:26:37
|
On Sunday 14 December 2008 23:29:13 Keith Marshall wrote: > FWIW, here is how I might implement them: > > $ cat <<EOF > asprintf.c > #include <stdio.h> > #include <stdarg.h> > #include <stdlib.h> > > int asprintf( char **, char *, ... ); > int vasprintf( char **, char *, va_list ); > > int vasprintf( char **sptr, char *fmt, va_list argv ) > { > int wanted = vsnprintf( *sptr = NULL, 0, fmt, argv ); > if( (wanted > 0) && ((*sptr = malloc( 1 + wanted )) != NULL) ) > return vsprintf( *sptr, fmt, argv ); > > return wanted; > } Except for the "deliberate" mistake; that doesn't work correctly, if vsnprintf() returns zero, or if malloc() fails! Here is a better implementation: int vasprintf( char **sptr, char *fmt, va_list argv ) { int wanted = vsnprintf( *sptr = NULL, 0, fmt, argv ); if( (wanted < 0) || ((*sptr = malloc( 1 + wanted )) == NULL) ) return -1; return vsprintf( *sptr, fmt, argv ); } Also note that my trivial test routine, (the `main()' function at the end), doesn't check for success of asprintf(); it will simply crash, if that fails. A real application should check for the failure case: int main() { char *retbuf; int len = asprintf( &retbuf, "%s", "An allocated string." ); if( len < 0 ) { fprintf( stderr, "asprintf failed\n" ); return 1; } else { printf( "Allocated %d + 1 bytes for string '%s'\n", len, retbuf ); free( retbuf ); return 0; } } Regards, Keith. |
From: Jonathan S. <js-...@we...> - 2008-12-19 13:05:51
Attachments:
signature.asc
|
Ok, I found out how to reprodue the problem. The -O2 flag is causing the problem. Take a look at this: asgard:/tmp$ cat asprintf.c #include <stdio.h> #include <stdlib.h> #include <stdarg.h> int asprintf(char **strp, const char *fmt, ...) { int size; va_list args; va_start(args, fmt); if ((size = vsnprintf(NULL, 0, fmt, args)) < 0) return size; if ((*strp = malloc((size_t)size + 1)) == NULL) return -1; return vsnprintf(*strp, (size_t)size + 1, fmt, args); } int main() { char *x; printf("ret: %d\n", asprintf(&x, "hello")); printf("ptr: %p\n", x); puts(x); return 0; } asgard:/tmp$ mingw32-gcc asprintf.c asgard:/tmp$ wine a.exe ret: 5 ptr: 00110888 hello Until here, everything works as expected. But look now at this (still the same file): asgard:/tmp$ mingw32-gcc -O2 asprintf.c asgard:/tmp$ wine a.exe ret: -1 ptr: 00000000 wine: Unhandled page fault on read access to 0x00000000 at address 0xb7dd7ab3 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xb7dd7ab3). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b7dd7ab3 ESP:0060fe5c EBP:0060fe88 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7ebe5d98 ECX:00000000 EDX:00000000 ESI:00000000 EDI:00401130 Stack dump: 0x0060fe5c: 7ebc5995 00000000 00403033 0060fe94 0x0060fe6c: 0060fe98 000000fc 7ebe5d98 0060fea8 0x0060fe7c: 7eeb19c0 7ffdf000 00401130 0060feb8 0x0060fe8c: 004013d0 00000000 00000000 0060feb8 0x0060fe9c: 0040139a 7ebebdc8 00401130 0060fec8 0x0060feac: 7ebbc51c 00000000 0060fed0 0060fef8 Backtrace: =>1 0xb7dd7ab3 strlen+0x33() in libc.so.6 (0x0060fe88) 2 0x004013d0 in a (+0x13d0) (0x0060feb8) 3 0x004010b6 in a (+0x10b6) (0x0060fef8) 4 0x00401148 in a (+0x1148) (0x0060ff08) 5 0x7ee74d97 start_process+0xc7(arg=0x0) [/tmp/wine-1.1.1/dlls/kernel32/process.c:904] in kernel32 (0x0060ffe8) 6 0xb7ed3587 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0xb7dd7ab3 strlen+0x33 in libc.so.6: movl 0x0(%eax),%ecx Modules: Module Address Debug info Name (15 modules) PE 400000- 40a000 Export a ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7eb99000-7ec01000 Deferred msvcrt<elf> \-PE 7ebb0000-7ec01000 \ msvcrt ELF 7ee01000-7ef2e000 Dwarf kernel32<elf> \-PE 7ee20000-7ef2e000 \ kernel32 ELF 7ef2e000-7ef38000 Deferred libnss_files.so.2 ELF 7ef38000-7ef5d000 Deferred libm.so.6 ELF 7ef5d000-7f000000 Deferred ntdll<elf> \-PE 7ef70000-7f000000 \ ntdll ELF b7d68000-b7d6c000 Deferred libdl.so.2 ELF b7d6c000-b7e9a000 Export libc.so.6 ELF b7e9a000-b7eb1000 Deferred libpthread.so.0 ELF b7ecc000-b8002000 Dwarf libwine.so.1 ELF b8003000-b801f000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\tmp\a.exe 00000009 0 <== 0000000c 00000013 0 00000012 0 0000000e 0 0000000d 0 0000000f 00000015 0 00000014 0 00000011 0 00000010 0 Backtrace: =>1 0xb7dd7ab3 strlen+0x33() in libc.so.6 (0x0060fe88) 2 0x004013d0 in a (+0x13d0) (0x0060feb8) 3 0x004010b6 in a (+0x10b6) (0x0060fef8) 4 0x00401148 in a (+0x1148) (0x0060ff08) 5 0x7ee74d97 start_process+0xc7(arg=0x0) [/tmp/wine-1.1.1/dlls/kernel32/process.c:904] in kernel32 (0x0060ffe8) 6 0xb7ed3587 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) So it seems mingw32-gcc uses a different vsnprintf when using -O2? -- Jonathan |
From: Roumen P. <bug...@ro...> - 2008-12-20 16:33:35
|
Jonathan Schleifer wrote: > I tried some more and it seems that snprintf always works, but > vsnprintf only works correctly when using -O0. This seems to be an > issue with the headers. > > I have shortened the test even more and compared the generated .s > files (I hope this is short enough now ;)): > > asgard:/tmp$ cat test.c > #include <stdio.h> > > int > main() > { > printf("%d\n", vsnprintf(NULL, 0, "asd", NULL)); > > return 0; > } > asgard:/tmp$ mingw32-gcc -O0 -S -o test0.s test.c > asgard:/tmp$ mingw32-gcc -O1 -S -o test1.s test.c > asgard:/tmp$ diff -u test0.s test1.s Interesting but with my cross-compiler difference is: $ diff -u foo-O0.s foo-O1.s --- foo-O0.s 2008-12-20 18:22:21.000000000 +0200 +++ foo-O1.s 2008-12-20 18:22:17.000000000 +0200 @@ -13,13 +13,7 @@ movl %esp, %ebp subl $24, %esp andl $-16, %esp - movl $0, %eax - addl $15, %eax - addl $15, %eax - shrl $4, %eax - sall $4, %eax - movl %eax, -4(%ebp) - movl -4(%ebp), %eax + movl $16, %eax call __alloca call ___main movl $0, 12(%esp) ,i.e. I see optimization and no difference in vsnprintf. $ gcc --version gcc (GCC) 3.4.5 (mingw special) Roumen |
From: Jonathan S. <js-...@we...> - 2008-12-20 16:35:58
Attachments:
PGP.sig
|
Am 20.12.2008 um 17:33 schrieb Roumen Petrov: > Interesting but with my cross-compiler difference is: > $ diff -u foo-O0.s foo-O1.s > --- foo-O0.s 2008-12-20 18:22:21.000000000 +0200 > +++ foo-O1.s 2008-12-20 18:22:17.000000000 +0200 > @@ -13,13 +13,7 @@ > movl %esp, %ebp > subl $24, %esp > andl $-16, %esp > - movl $0, %eax > - addl $15, %eax > - addl $15, %eax > - shrl $4, %eax > - sall $4, %eax > - movl %eax, -4(%ebp) > - movl -4(%ebp), %eax > + movl $16, %eax > call __alloca > call ___main > movl $0, 12(%esp) > > ,i.e. I see optimization and no difference in vsnprintf. Thanks for testing! So it seems this only happens with gcc 4.3? -- Jonathan |
From: Jonathan S. <js-...@we...> - 2008-12-20 12:09:09
Attachments:
signature.asc
|
I tried some more and it seems that snprintf always works, but vsnprintf only works correctly when using -O0. This seems to be an issue with the headers. I have shortened the test even more and compared the generated .s files (I hope this is short enough now ;)): asgard:/tmp$ cat test.c #include <stdio.h> int main() { printf("%d\n", vsnprintf(NULL, 0, "asd", NULL)); return 0; } asgard:/tmp$ mingw32-gcc -O0 -S -o test0.s test.c asgard:/tmp$ mingw32-gcc -O1 -S -o test1.s test.c asgard:/tmp$ diff -u test0.s test1.s --- test0.s 2008-12-20 12:57:51.641853580 +0100 +++ test1.s 2008-12-20 12:57:58.272853142 +0100 @@ -21,17 +21,15 @@ pushl $LC0 pushl $0 pushl $0 - call _vsnprintf - addl $16, %esp - subl $8, %esp + call __vsnprintf + addl $8, %esp pushl %eax pushl $LC1 call _printf - addl $16, %esp movl $0, %eax movl -4(%ebp), %ecx leave leal -4(%ecx), %esp ret + .def __vsnprintf; .scl 2; .type 32; .endef .def _printf; .scl 2; .type 32; .endef - .def _vsnprintf; .scl 2; .type 32; .endef As you can see, mingw32 references _vsnprintf instead of vsnprintf when specifying -O1 or higher. When using the following test code, it even works with -O6: asgard:/tmp$ cat test.c #include <stddef.h> #include <stdarg.h> extern int printf(char*, ...); extern int vsnprintf(char*, size_t, char*, va_list); int main() { printf("%d\n", vsnprintf(NULL, 0, "asd", NULL)); return 0; } asgard:/tmp$ mingw32-gcc -O6 test.c asgard:/tmp$ wine a.exe 3 This looks like a bug in the headers to me, or did I mis something? -- Jonathan |
From: Keith M. <kei...@us...> - 2008-12-20 15:33:30
|
On Saturday 20 December 2008 12:08:58 Jonathan Schleifer wrote: [vsnprintf() not working as expected; minimal test case provided]: > #include <stddef.h> > #include <stdarg.h> Ok, I claim the prize for spotting the deliberate mistake here. All bets are off, when you fail to #include the minimally required set of headers; stdio.h is required, but conspicuous by its absence... > extern int printf(char*, ...); > extern int vsnprintf(char*, size_t, char*, va_list); ...and by doing this yourself, you don't get the correct definitions, specific to the MinGW implementation, which are provided by stdio.h... > int > main() > { > printf("%d\n", vsnprintf(NULL, 0, "asd", NULL)); ...so here, you will get only the default, non-standard, MSVCRT implementation, instead of the enhanced MinGW implementation you were hoping to get. > return 0; > } -- Regards, Keith. |
From: Jonathan S. <js-...@we...> - 2008-12-20 15:44:14
Attachments:
signature.asc
|
Keith Marshall <kei...@us...> wrote: > On Saturday 20 December 2008 12:08:58 Jonathan Schleifer wrote: > [vsnprintf() not working as expected; minimal test case provided]: > > #include <stddef.h> > > #include <stdarg.h> > > Ok, I claim the prize for spotting the deliberate mistake here. All > bets are off, when you fail to #include the minimally required set of > headers; stdio.h is required, but conspicuous by its absence... No, no, no! Don't confuse the seconf test with the first! Look at the first! The *FIRST* fails, which should succeed. The second, where you say it will fail, *WORKS*. > > extern int printf(char*, ...); > > extern int vsnprintf(char*, size_t, char*, va_list); > > ...and by doing this yourself, you don't get the correct definitions, > specific to the MinGW implementation, which are provided by stdio.h... By doing that, I *GET* the right definition of vsnprintf. Please look *CAREFULLY* at the output, this is the version that works. When including <stdio.h>, the bug occours. > > int > > main() > > { > > printf("%d\n", vsnprintf(NULL, 0, "asd", NULL)); > > ...so here, you will get only the default, non-standard, MSVCRT > implementation, instead of the enhanced MinGW implementation you were > hoping to get. > > > return 0; > > } -- Jonathan |
From: Jonathan S. <js-...@we...> - 2008-12-22 02:11:25
Attachments:
PGP.sig
|
Using gcc 4.3.2 with tdm-2 patches, gcc references to __vsnprintf instead of _vsnprintf when using -O1 as well. Also tried it with mingw32-gcc 3.4.5-20060117 and got the same result. As it worked for Roumen Petrov and I had the issue with different versions, I think it's possible it could be something with the rest of my mingw32 installation. Any ideas what it could be? -- Jonathan |
From: Jonathan S. <js-...@we...> - 2008-12-22 02:41:05
Attachments:
PGP.sig
|
I think I found the reason: I have a directory /usr/mingw32/sys- include (I don't know where it's coming from) which has an stdio.h containing: __CRT_INLINE int __cdecl vsnprintf (char* s, size_t n, const char* format, __VALIST arg) { return _vsnprintf ( s, n, format, arg); } Commenting this code out fixes the problem. As I don't know where the sys-include directory comes from, I removed it and erverything seems to work fine now. -- Jonathan |