2009/12/23 Chris Sutcliffe :
> With the latest gcc/g++ I'm having issues with dllimport / dllexport.
> I have an old version of the mingw-w64 compiler hanging around:
>
> x86_64-w64-mingw32-g++.exe (GCC) 4.5.0 20091011 (experimental)
>
> which works fine, however the same code compiled with this ve
With the latest gcc/g++ I'm having issues with dllimport / dllexport.
I have an old version of the mingw-w64 compiler hanging around:
x86_64-w64-mingw32-g++.exe (GCC) 4.5.0 20091011 (experimental)
which works fine, however the same code compiled with this version:
x86_64-w64-mingw32-g++.exe (GCC
more
>>> maintained and complete than mingw32.
>>>
>>> While trying to do so, I get the following... And indeed the
>>> declaration is duplicated.
>>> I tested both v1.0 and trunk snapshots, gcc is 4.4.2.
>>>
>>> x86_64-w64-mingw32 compi
Thanks!
Will use __printf__, I even see it is documented Sorry.
On Tue, Dec 22, 2009 at 9:50 PM, Kai Tietz wrote:
> 2009/12/22 Alon Bar-Lev :
>> #define _POSIX
>> #include
>>
>> int my_printf(char *format, ...) __attribute__((format(printf,1,2)));
>>
>> int main(void) {
>> return 0;
>
On Tue, Dec 22, 2009 at 10:01 PM, Kai Tietz wrote:
> Well, we have here (at least for the native printf functions) to
> assume smallest supported feature-set. By using msvcrt.dll (Vista or
> newer) you are using in fact msvcr80.dll + feature set, which supports
> %ll specifier, but older ms runtim
gt;
>> While trying to do so, I get the following... And indeed the
>> declaration is duplicated.
>> I tested both v1.0 and trunk snapshots, gcc is 4.4.2.
>>
>> x86_64-w64-mingw32 compiles OK.
>>
>> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mi
2009/12/22 Alon Bar-Lev :
> On Tue, Dec 22, 2009 at 7:53 PM, Tor Lillqvist wrote:
>>> But this is *UGLY* And I don't have inttypes.h on all platforms...
>>> For example solaris8 does not define these constants.
>>
>> That is why there exists libraries and higher level languages that
>> make po
ation is duplicated.
> I tested both v1.0 and trunk snapshots, gcc is 4.4.2.
>
> x86_64-w64-mingw32 compiles OK.
>
> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
> error: conflicting
2009/12/22 Alon Bar-Lev :
> #define _POSIX
> #include
>
> int my_printf(char *format, ...) __attribute__((format(printf,1,2)));
>
> int main(void) {
> return 0;
> }
>
> $ x86_64-w64-mingw32-gcc -pedantic a.c
> a.c:4: warning: ‘__mingw_printf’ is an unrecognized format function type
This is
Hello,
well this macros had one typo and an illegal assignment.
This code should work, but of course you can use memset instead of
assigning to __tm_zero, too.
#include
static struct tm __tm_zero;
#define localtime_r_1(_Time, _Tm) ({ struct tm *___tmp_tm = \
On Tue, Dec 22, 2009 at 7:53 PM, Tor Lillqvist wrote:
>> But this is *UGLY* And I don't have inttypes.h on all platforms...
>> For example solaris8 does not define these constants.
>
> That is why there exists libraries and higher level languages that
> make portability easier.
>
> For instanc
#define _POSIX
#include
int my_printf(char *format, ...) __attribute__((format(printf,1,2)));
int main(void) {
return 0;
}
$ x86_64-w64-mingw32-gcc -pedantic a.c
a.c:4: warning: ‘__mingw_printf’ is an unrecognized format function type
---
> But this is *UGLY* And I don't have inttypes.h on all platforms...
> For example solaris8 does not define these constants.
That is why there exists libraries and higher level languages that
make portability easier.
For instance, GLib has G_GINT64_FORMAT. And then there is Java.
--tml
On Tue, Dec 22, 2009 at 7:44 PM, Tor Lillqvist wrote:
>> I found [1], which states that Microsoft does not support %ll variant.
>> But I checked this in Visual Studio and it is supported.
>> So where is the catch?
>
> There are several different C libraries from Microsoft. Some support
> %ll, some
> I found [1], which states that Microsoft does not support %ll variant.
> But I checked this in Visual Studio and it is supported.
> So where is the catch?
There are several different C libraries from Microsoft. Some support
%ll, some don't. (They all support %I64d.) Use PRId64 etc from
, that's
Hello,
I found [1], which states that Microsoft does not support %ll variant.
But I checked this in Visual Studio and it is supported.
So where is the catch?
Thanks,
Alon.
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=2818436&group_id=2435&atid=102435
--
Something is invalid with these macros.
Takes localtime_r for example... Both the GNU and standard cannot be compiled...
Is it just me?
#include
#define localtime_r_1(_Time, _Tm) ({ struct tm *___tmp_tm =
\
localtime((_Time)); \
is 4.4.2.
x86_64-w64-mingw32 compiles OK.
/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
error: conflicting types for ‘_mm_shuffle_ps’
/usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note
Hi Nick!
Nick Mathewson wrote:
On Fri, Dec 18, 2009 at 04:53:41PM -0500, Patrick Galbraith wrote:
[...]
@@ -11,6 +11,6 @@
Requires:
Conflicts:
Libs: -L${libdir} -levent
-Libs.private:
+Libs.private: -lws2_32
Cflags: -I${includedir}
Hm. Is there some way to do th
Thank you again.
On Tue, Dec 22, 2009 at 1:45 PM, Kai Tietz wrote:
> Sorry for being that lazy. I updated the svn snapshots on our download
> page. We provide additional source balls for toolchain build, but
> those aren't svn snapshots.
>
> You can find two different versions of source snapshots
2009/12/22 Alon Bar-Lev :
> Thanks!
>
> When are you going to publish a new snapshot?
> Current snapshot is mingw-w64-snapshot-20090419.tar.bz2 and is it very old.
>
> Vapier, the lord of toolchain in Gentoo, recently added out-of-the-box
> support for mingw64... However he will only use formal sna
Thanks!
When are you going to publish a new snapshot?
Current snapshot is mingw-w64-snapshot-20090419.tar.bz2 and is it very old.
Vapier, the lord of toolchain in Gentoo, recently added out-of-the-box
support for mingw64... However he will only use formal snapshots for
the runtime.
Can you pleas
Alon Bar-Lev wrote on 21.12.2009 17:30:04:
> Hello,
>
> Can this be added?
>
> Should be:
> typedef enum _HTTP_DATA_CHUNK_TYPE {
> HttpDataChunkFromMemory,HttpDataChunkFromFileHandle,
> HttpDataChunkFromFragmentCache,HttpDataChunkFromFragmentCacheEx,
> HttpDataChunkMaximum
> } HTTP_DATA
23 matches
Mail list logo
