> 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
--
> 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
> 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
> 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
> 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
> 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
> 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
--
> 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
> 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
> 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
> 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
---
> 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
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
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"
> 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
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
> 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
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
18 matches
Mail list logo