Basic bootstrapping-queries on MinGW

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Basic bootstrapping-queries on MinGW

Ajay Garg
Hi All.

We have a framework, which we have ported on a number of systems of following types ::

      * linux on vanilla desktops
      * linux-like-OS on routers
      * SOCs without any OS


Now, we wish to port the framework to Windows.

As the first step, I am wondering if MinGW would be a good choice, as it will allow compiling on Linux.
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, and the binary run on Windows-7.
However, I see that "usleep" does not work on Windows as expected (it works flawlessly on Linux).

Bigger beasts like sockets and multi-threading support still await their turn to be ported to Windows.


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 MSDN-APIs)?


Will be grateful for pointers.


Thanks and Regards,
Ajay

------------------------------------------------------------------------------
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
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Basic bootstrapping-queries on MinGW

Eli Zaretskii
> From: Ajay Garg <[hidden email]>
> Date: Sat, 5 Nov 2016 22:48:27 +0530
>
> However, I see that "usleep" does not work on Windows as expected (it works flawlessly on Linux).
>
> Bigger beasts like sockets and multi-threading support still await their turn to be ported to Windows.
>
> 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 MSDN-APIs)?

I don't understand you concerns.  If you worry about standard
functions, like usleep and sockets and multi-threading, then Visual
Studio won't solve them, since MinGW uses the same runtime C libraries
as the Studio.

I think the real choice is between MinGW/Studio and Cygwin.  The
latter will give you all you want, but the price is that you need to
distribute the Cygwin DLL with your binaries.

------------------------------------------------------------------------------
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
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Basic bootstrapping-queries on MinGW

K. Frank
In reply to this post by Ajay Garg
Hi Ajay!

On Sat, Nov 5, 2016 at 1:18 PM, Ajay Garg <[hidden email]> wrote:

> Hi All.
>
> We have a framework, ...
>
> Now, we wish to port the framework to Windows.
>
> As the first step, I am wondering if MinGW would be a good choice, as it
> will allow compiling on Linux.
> As a first step, I have got the most minimal portion of the framework ported
> using MinGW, and things "mostly" work on Windows.

MinGW compiles portable c++ code (mostly) fine on windows.

> ...
> However, I see that "usleep" does not work on Windows as expected (it works
> flawlessly on Linux).

MinGW does not emulate unix-style os api's for you.  (If you want something
like that you would need an os emulation layer like cygwin.)

> Bigger beasts like sockets

Windows offers its native socket api's, winsock and winsock2.  There are
some substantive differences between those and unix sockets, but I've found
porting unix socket code to windows to be generally straightforward.

I have used MinGW (actually, a related forked project) to build projects
that used unix sockets on windows.  I had to tweak some of the socket
stuff to make it work with winsock, but it wasn't too bad.

> and multi-threading support still await their turn to be ported to Windows.

There is a windows ports of pthreads, pthreads-win32, that plays well with
MinGW.  MinGW also supports (or can be made to support) c++11's
std::thread if you're willing to use pthreads-win32 underneath.

MinGW also supports the native windows threading api's.  (Unlike sockets,
windows threading is quite different from pthreads, so porting pthreads
code to native windows threading is a lot more than just a few tweaks.)

> 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 MSDN-APIs)?

MinGW supports most of the official windows os api's.  (It doesn't implement
that functionality -- that is in the microsoft dll's that ship with
the os -- but it
does give you headers with the appropriate function declarations.)

If by MSDN-APIs you mean windows os api's, then you should be pretty
well covered.  If you mean api's that are implemented by microsoft products
(including visual studio) other than the windows os itself, then not so much.
But, because you're bringing your framework over from the unix world, I
wouldn't expect that you would be using too much microsoft-specific stuff.

> Will be grateful for pointers.
>
> Thanks and Regards,
> Ajay


Good luck.


K. Frank

------------------------------------------------------------------------------
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
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Basic bootstrapping-queries on MinGW

Keith Marshall-3
In reply to this post by Ajay Garg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> Linux).

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
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/mingwrt/include/time.h
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)?

Yes!

> Or we use should Visual-Studio (on Windows) itself to compile the
> framework (as that will also provide the luxury of using the
> MSDN-APIs)?

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.

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYHlEyAAoJEMCtNsY0flo/R+0P/017gMQRugxRYCyuX/hARK06
sg0w0kUc6BdmBnF211nNH9IL2UrcQ/gfgTxvd4RVfmvbblDMw92RDRJPqIKlDaJN
gkapSGhOSWrqBis1KQbbTWOMNXgOGMecPp+5igMizYG2vnEDa0BWYiLAw8tu6Bgw
uk1Bx9jaACLDuj4lUehKLCiznanlkcjxhBQN2ehZy4uDZc6cWl7nYmO3zzIRPwDn
YdmnEVhc8UOocwpf/8eEj4Q09rXvbcE2Ixif5ar5y2WBoQzv9pKClf0xR3ZrDQ0Q
OwCwRkX1AZMbVxfrCEIzExg8cp33SxltuYMjWqOab7cDVRH/FVv/sE7VqiVat8yN
2s4PC+QWbqNpmKZOY4goNM4E3s5BX//DAfH37ekOVdW1uFfwYsR7vYoiwZ9lnVrl
EMZN7yIIUwrCUZ+YwTAvSK0q1QA3wHyatfrXWEamIELhuQlxjbSFUJnPEOuwZD0Z
zIuHIzfvInGBWOdHIW/Kh3VgAewKf0BNT2WXe5iMTl6bpxp8RiUnfHcf1DJibGM0
HZuKpnmVixXgEIzjzt6A8FzrRjUEzWKd63NXy5Z2hQC7LvD/Gv8ad8uv+05hNT9S
t5AFfvGDqfVsWKHAHnuYqA8ul1X47nvVZxer1/tO4ep4zQgy0t10L72p8Ce27Agw
nBm6cDErNe63XC/t+Lj4
=V5yI
-----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
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe