Re: [Mingw-users] Basic bootstrapping-queries on MinGW
-----BEGIN PGP SIGNED MESSAGE-----
On 05/11/16 17:18, Ajay Garg wrote:
> We have a framework, which ... we wish to port to Windows.
> As the first step, I am wondering if MinGW would be a good choice,
> as it will allow compiling on Linux.
Given that I cross-compiled most of the recent MinGW.org published code
on my own LinuxMint-DebianEdition host, I'd have to say "yes".
> As a first step, I have got the most minimal portion of the
> framework ported using MinGW, and things "mostly" work on Windows.
> I say mostly, because the bare-metal-part-of-the-code works fine
> when the code is compiled using i586-mingw32msvc-gcc, ...
Really? Does that oxymoron still have some sort tenuous hold on life?
I know there's a temptation to use whatever the Linux distributor has
in their package repository, but do you *really* trust such a package
to be kept bang up to date? I certainly don't, and I've always built
my own mingw32-gcc cross, from original GNU source.
> ... and the binary run on Windows-7. However, I see that "usleep"
> does not work on Windows as expected (it works flawlessly on
It should also work just fine on Windows, if you have a version of
mingwrt which is more recent than mingwrt-3.21[*]; (and if your Linux
package gives you mingwrt-4.x, it is both *older* than mingwrt-3.21,
and it is comprehensively broken). That said, why are you using
usleep() anyway? POSIX.1-2008 declared it obsolete, (and dropped all
related documentation); MinGW retains its implementation, but should
emit a "deprecated function" warning at compile time. The preferred
alternative is nanosleep(), (but do note you most definitely will
*never* achieve ns timing resolution on Windows; see the comments in
for an explanation).
[*] The current stable release is mingwrt-3.22.4, which should be
accompanied by w32api-3.18.2; anything older may still exhibit bugs
which have been fixed in the meantime.
> With the above back-story, what do the experts think? Is it
> worthwhile to go with MinGW-toolchain (on Linux)?
> Or we use should Visual-Studio (on Windows) itself to compile the
> framework (as that will also provide the luxury of using the
Luxury? Not in the least. If you value portability of your framework,
why on earth would you want to write it twice? MSDN APIs == Microsoft
lock-in; the complete antithesis of portability.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: