Re: [Mingw-w64-public] Adding perl to Projects successfully using MinGW-w64

2010-05-12 Thread Tor Lillqvist
> The Perl that comes > with either msys or msysgit is really ancient and pretty much unusable. Unusable for your needs, you mean. They have both worked fine for me. --tml --

Re: [Mingw-w64-public] problem with i64 in C, C++

2010-05-08 Thread Tor Lillqvist
> in MSVC++, you do > __int64 n=9223372036854775807i64; > but in all forms of GCC, including mingw-w64, you do > #include > __int64 n=9223372036854775807LL; Welcome to Portable Programming 101. Rule 1: Don't assume that things that happen to work in one compiler also work in another. This goes "b

Re: [Mingw-w64-public] MinGW-w64 and DDK headers

2010-05-03 Thread Tor Lillqvist
> It is nice to be able to use the same open toolchain for both > application and driver development... Hmm, for application development, especially in cases where existing makefilery, autowhatever etc strongly is geared towards gcc and the rest of a GNU toolchain, sure. But for driver developmen

Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC

2010-03-09 Thread Tor Lillqvist
> shame that the msvc (and subsequently mingw) does a > #define MAXIMUM_PROCESSORS 32 > it seems these days that limits are meant to be broken, That #define certainly does not mean that code built with mingw (or msvc) would be limited to running threads on a maximum of 32 concurrent processors, if

Re: [Mingw-w64-public] libmangle?

2010-03-04 Thread Tor Lillqvist
> Maybe, but exception handling still won't work. Isn't there other things also that are incompatible, like vtables and whatnot? Doesn't some FAQ say that different C++ compilers use different name mangling on purpose because even if they would use the same mangling, one could still not in general

Re: [Mingw-w64-public] cross compiler uses 32 bits long type and cannot be changed into 64 bits

2010-02-25 Thread Tor Lillqvist
> Why can a long integer not be set to 64 bits? Because long is32 bits in the 64-bit Windows ABI, and in also 64-bit C libraries on Windows. And this is fully legal from a C language point of view. Any code that pretends to be portable but assumes long is 64 bits is simply broken. Code should us

Re: [Mingw-w64-public] Question on scanf and modifiers...

2010-01-30 Thread Tor Lillqvist
> I know it wasn't long ago that I was asking about using %llu in fscanf or > sscanf.  However, I am wondering if anything has changed in this regard?  Does > MingW64 support %llu in the scanf functions? Use SCNu64 from . That's what it's for. --tml --

Re: [Mingw-w64-public] printf %ll

2009-12-22 Thread Tor Lillqvist
> 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

Re: [Mingw-w64-public] printf %ll

2009-12-22 Thread Tor Lillqvist
> 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

Re: [Mingw-w64-public] how to invoke (install?) mingw64.

2009-04-25 Thread Tor Lillqvist
> But how does one check an image to directly to see if it's compiled 32 or 64 > bits? objdump -h for instance. An objdump built for just 32-bit mingw won't even recognize a 64-bit binary. An objdump built for 64-bit mingw will tell you that a 32-bit binary is "file format pei-i386" and a 64-bit i

Re: [Mingw-w64-public] how to invoke (install?) mingw64.

2009-04-24 Thread Tor Lillqvist
> What would be the barebones gcc command, using mingw64, to build a > sample hello.c? On a 64-bit Windows system, presumably: gcc -o hello.exe hello.c. Using a cross-compiler: x86_64-pc-mingw32-gcc -o hello.exe hello.c --tml ---

Re: [Mingw-w64-public] distraction with gethostbyname with SysWOW64.

2009-03-10 Thread Tor Lillqvist
> My question is: Is it possible to put write a workaround for this bug either > by > modifying the atrtached test code Use getaddrinfo() instead? > or by adapting the gcc mingw-w32 toolchain? I don't think so. --tml

Re: [Mingw-w64-public] [patch] add gmtime_r() support

2009-02-08 Thread Tor Lillqvist
Please note that plain old gmtime() and localtime() *are* thread-safe in Microsoft's C library. They use a thread-local buffer. (That doesn't be that they would be especially nice APIs, though, using an implicit buffer. But Unix programmers managed fine with them until threads became popular. gmti

Re: [Mingw-w64-public] pexports for 64-bit binaries?

2008-08-30 Thread Tor Lillqvist
I wrote: > I will have a go at porting it to handle 64-bit PE binaries. Done. Cleaned it up a bit, it now compiles without warnings both as a 32-bit and 64-bit program (and in either case reads both 32-bit and 64-bit DLLs). Sources in http://tml.pp.fi/pexports-0.44.zip . Still not a very "clean"

Re: [Mingw-w64-public] pexports for 64-bit binaries?

2008-08-30 Thread Tor Lillqvist
> I don't know what that is. Do you have a link for it? It's apparently a quite old and small program. Not related to gcc or other GNU tools, but included in the 32-bit mingw distribution, at least for Win32, don't know about the cross-compiling mingw distributions. The sources seem to be for ins

[Mingw-w64-public] pexports for 64-bit binaries?

2008-08-29 Thread Tor Lillqvist
Anybody have a version of pexports for 64-bit binaries? Apparently it is no part of the gcc toolchain as mingw-w64 doesn't come with it? At least for 32-bit binaries, I often find pexports more useful than objdump -p (or link -dump -exports), especially as pexports's output is in .def file format r

Re: [Mingw-w64-public] Problem with main() parameters in subsystem:windows apps

2008-08-08 Thread Tor Lillqvist
> The arguments passed here are bogus. > You should use instead the standard function WinMain as entry proint for > your user application. You mean using the -e flag? Would that be -e _WinMain then? That is different from both "normal" 32-bit mingw and MSVS conventions then... The 32-bit mingw use

[Mingw-w64-public] Problem with main() parameters in subsystem:windows apps

2008-08-07 Thread Tor Lillqvist
Hi, I recently built the GTK+ stack and its dependencies with mingw-w64 (as cross-compilation from win32), and was pleasantly surprised with how easy it was. Then I built GIMP, but there I ran into just one problem: In an executable built with -mwindows, the argc and argv parameters to main() are