MinGW - Minimalist GNU for Windows

> Couple questions:
> 1) Does Cygwin + --no-cygwin =3D MinGW ?
>      and generate native windows code ?
>=20
> 2) There is a gcc-mingw package in Cygwin distribution.
>     Is that the same one which I found in http://www.mingw.org ?
>     What's the different ?
>=20
> 3) Does library created by Cygwin can be used directly
>     under MinGW ?

All these questions seem to be cygwin related and probably should
be asked there. However:
1) No.
   Don't know.
2) Don't know but I'd assume No.
   Under the assumption the above No is correct then it probably
   is build for the cygwin compatibility layer. The package on
   http://www.mingw.org is for native Win32 and does not require the
   cygwin compatibility layer.
3) Yes
   with the (obious?) exception that libraries that rely on
   special cygwin features (like e.g. Posix stuff) won't.

The short and simplified difference between cygwin and mingw is
that mingw strives to provide a native Win32 compiler toolchain
that could replace MSVC (or Borland or...) while cygwin strives
to provide a complete Posix environment for Win32 thus allowing
easy porting of e.g. Linux sources to Win32.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Michael Gerdau wrote:

> All these questions seem to be cygwin related and probably should
> be asked there. However:
> 1) No.
>    Don't know.
> 2) Don't know but I'd assume No.
>    Under the assumption the above No is correct then it probably
>    is build for the cygwin compatibility layer. The package on
>    http://www.mingw.org is for native Win32 and does not require the
>    cygwin compatibility layer.
> 3) Yes
>    with the (obious?) exception that libraries that rely on
>    special cygwin features (like e.g. Posix stuff) won't.
> 
> The short and simplified difference between cygwin and mingw is
> that mingw strives to provide a native Win32 compiler toolchain
> that could replace MSVC (or Borland or...) while cygwin strives
> to provide a complete Posix environment for Win32 thus allowing
> easy porting of e.g. Linux sources to Win32.

Uh, what?  The gcc that you get under Cygwin with -mno-cygwin is
*identical* to the mingw gcc.  It's built from gcc sources downloaded
from mingw.org ferchrissake.  It uses the exact same mingw-runtime and
w32api sources too, in fact they share the same CVS repository.  For all
intents and purposes you should bit for bit identical binary output
(assuming you pick corresponding versions of
{gcc,binutils,mingw-runtime,w32api}) for cygwin's "gcc -mno-cygwin" and
the mingw gcc.

The entire point of -mno-cygwin is to provide quick and easy access to
the mingw toolchain from within cygwin.  Binaries compiled this way have
absolutely zero dependance on cygwin.

Brian

Hi Brian,

The reason I asked this is I want to use ORBit2 under Windows.
The Cygwin version of ORBit2 is quite slow (I measure the overhead
from WinXP/cygwin to Linux across 100Mb network and get ~ 18msec.
It's only ~0.5msec for the same test from Linux to Linux).

I'm planning to re-built ORBit2 from source under MinGW and hopefully
get better performance.  But I'm a little confused by cygwin and MinGW ...

Thanks
KC


>
> Uh, what?  The gcc that you get under Cygwin with -mno-cygwin is
> *identical* to the mingw gcc.  It's built from gcc sources downloaded
> from mingw.org ferchrissake.  It uses the exact same mingw-runtime and
> w32api sources too, in fact they share the same CVS repository.  For all
> intents and purposes you should bit for bit identical binary output
> (assuming you pick corresponding versions of
> {gcc,binutils,mingw-runtime,w32api}) for cygwin's "gcc -mno-cygwin" and
> the mingw gcc.
>
> The entire point of -mno-cygwin is to provide quick and easy access to
> the mingw toolchain from within cygwin.  Binaries compiled this way have
> absolutely zero dependance on cygwin.
>
> Brian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

KC wrote:

> get better performance.  But I'm a little confused by cygwin and MinGW ...

The cygwin gcc packages include -mno-cygwin as a shortcut to compiling
with the mingw toolchain.  It's really two different compilers, or at
the very least two completely different C runtimes.

Porting a *nix-like package to windows using mingw can sometimes be
easy, but often it is quite difficult without some manual labor because
of the fact that MSVCRT provides very little of the posix API past what
the C language requires.  So if your app expects to do anything "unix
like" such as fork/exec you either have to rewrite it using win32
concepts or use an emulation library like Cygwin.  If you use Cygwin you
can compile a much wider array of posix software out of the box without
modification, but there is some overhead.

I don't know anything about Orbit2, but it looks like it's network-IO
bound.  If that is the case then I doubt that Cygwin has anything to do
with the perceived latency, and I suggest that the difference is
inherently a windows issue and won't change just because you avoid
Cygwin.  There was a recent thread on the cygwin ML regarding Windows'
poor implementation of the TCP/IP nagle algorithm, and the need to set
TCP_NODELAY.  You might want to read that:
<http://cygwin.com/ml/cygwin/2006-03/msg00424.html>

On the other hand if the library is just doing network IO then it
shouldn't be too hard to port to mingw, and it would seem that others
have had success doing this with relatively few changes:
<http://mail.gnome.org/archives/orbit-list/2006-February/msg00000.html>.

Brian

> Uh, what?  The gcc that you get under Cygwin with -mno-cygwin is
> *identical* to the mingw gcc.  It's built from gcc sources downloaded
> from mingw.org ferchrissake.
[snip]

Oups.

I stand corrected (and learned something new, at least for me).

Sorry for the confusion, best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Hi Michael,

Thanks for the info.
ORBit2 is an implementation of CORBA 2.4 which is similar to DCOM
and it's the only implemenation of C language mapping of CORBA, AFAIK.


KC


On 3/27/06, Brian Dessent <brian@...> wrote:
> KC wrote:
>
> > get better performance.  But I'm a little confused by cygwin and MinGW =
...
>
> The cygwin gcc packages include -mno-cygwin as a shortcut to compiling
> with the mingw toolchain.  It's really two different compilers, or at
> the very least two completely different C runtimes.
>
> Porting a *nix-like package to windows using mingw can sometimes be
> easy, but often it is quite difficult without some manual labor because
> of the fact that MSVCRT provides very little of the posix API past what
> the C language requires.  So if your app expects to do anything "unix
> like" such as fork/exec you either have to rewrite it using win32
> concepts or use an emulation library like Cygwin.  If you use Cygwin you
> can compile a much wider array of posix software out of the box without
> modification, but there is some overhead.
>
> I don't know anything about Orbit2, but it looks like it's network-IO
> bound.  If that is the case then I doubt that Cygwin has anything to do
> with the perceived latency, and I suggest that the difference is
> inherently a windows issue and won't change just because you avoid
> Cygwin.  There was a recent thread on the cygwin ML regarding Windows'
> poor implementation of the TCP/IP nagle algorithm, and the need to set
> TCP_NODELAY.  You might want to read that:
> <http://cygwin.com/ml/cygwin/2006-03/msg00424.html>
>
> On the other hand if the library is just doing network IO then it
> shouldn't be too hard to port to mingw, and it would seem that others
> have had success doing this with relatively few changes:
> <http://mail.gnome.org/archives/orbit-list/2006-February/msg00000.html>.
>
> Brian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

My personal reason to prefer mingw (plus MSYS) to Cygwin's gcc
-mno-cygwin is not any difference in gcc (and binutils) as such, but
the autoconfigury and libtool. It's much easier to get things mixed up
in Cygwin, if libtool gets confused by finding some Cygwin libraries,
for instance. If you can get around that, or don't use libtool or
autofoo at all, there shouldn't be any difference.

--tml

Hi all,

Regarding this issue I had a problem about MinGW + MSys, with respect to
Cygwin
(actually that is the reason I joined the list)

Environment:

HP Compaq Laptop that logs onto a Windows Domain

Scenario 1: (No network connection to the domain)

-- MSys will take ages to start (around 15 seconds).
-- If I start xemacs inside MSys it will start fast
-- But executing any process (like compiling) within XEmacs yields =
another
15 seconds

-- Cygwin will behave as expected: No delays ...

Scenario 2: (Network connection to the domain)

-- Both Msys and Cygwin behave the same: All right

Any clues ?

Regards


Daniel J. Rodr=EDguez


-----Mensaje original-----
De: mingw-users-admin@...
[mailto:mingw-users-admin@...] En nombre de KC
Enviado el: lun, 27 de marzo de 2006 07:58
Para: mingw-users@...
Asunto: Re: [Mingw-users] Fwd: cygwin + --no-cygwin =3D MinGW ??

Hi Michael,

Thanks for the info.
ORBit2 is an implementation of CORBA 2.4 which is similar to DCOM
and it's the only implemenation of C language mapping of CORBA, AFAIK.


KC


On 3/27/06, Brian Dessent <brian@...> wrote:
> KC wrote:
>
> > get better performance.  But I'm a little confused by cygwin and =
MinGW
...
>
> The cygwin gcc packages include -mno-cygwin as a shortcut to compiling
> with the mingw toolchain.  It's really two different compilers, or at
> the very least two completely different C runtimes.
>
> Porting a *nix-like package to windows using mingw can sometimes be
> easy, but often it is quite difficult without some manual labor =
because
> of the fact that MSVCRT provides very little of the posix API past =
what
> the C language requires.  So if your app expects to do anything "unix
> like" such as fork/exec you either have to rewrite it using win32
> concepts or use an emulation library like Cygwin.  If you use Cygwin =
you
> can compile a much wider array of posix software out of the box =
without
> modification, but there is some overhead.
>
> I don't know anything about Orbit2, but it looks like it's network-IO
> bound.  If that is the case then I doubt that Cygwin has anything to =
do
> with the perceived latency, and I suggest that the difference is
> inherently a windows issue and won't change just because you avoid
> Cygwin.  There was a recent thread on the cygwin ML regarding Windows'
> poor implementation of the TCP/IP nagle algorithm, and the need to set
> TCP_NODELAY.  You might want to read that:
> <http://cygwin.com/ml/cygwin/2006-03/msg00424.html>
>
> On the other hand if the library is just doing network IO then it
> shouldn't be too hard to port to mingw, and it would seem that others
> have had success doing this with relatively few changes:
> =
<http://mail.gnome.org/archives/orbit-list/2006-February/msg00000.html>.
>
> Brian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language
that extends applications into web and mobile media. Attend the live =
webcast
and join the prime developer group breaking into this new coding =
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Quoting KC <kcc1967@...>:

> Hi Michael,
>
> Thanks for the info.
> ORBit2 is an implementation of CORBA 2.4 which is similar to DCOM
> and it's the only implemenation of C language mapping of CORBA, AFAIK.
>

I know that ACE/TAO is already MinGW compliant and builds with 
MSYS/MinGW.  This isn't to say that ORBit2 isn't; I don't know that.

HTH,
Earnie Boyd

http://shop.siebunlimited.com

> I know that ACE/TAO is already MinGW compliant and builds with 
 > MSYS/MinGW.  This isn't to say that ORBit2 isn't; I don't know that.

Sure, ORBit2 builds with MinGW. In fact, on Win32 it *only* builds
with MinGW, not MSVC... The reason for this is that the code produced
by the ORBit2 IDL compiler requires features that only the GNU
linker's --enable-runtime-pseudo-reloc offers on Win32... I suspect
ORBit2 wasn't really designed with portability to Win32 and other
non-ELF platforms in mind.

--tml

Hi Tor,

Do you know any binary distribution of ORBit2-MinGW exist ?
Re-compile ORBit2 under MinGW is not easy because
ORBit2 depends on pkconfig, glib, linc (maybe), libIDL ....
None of these have binary distribution could be found
on MinGW's web site.

Regards
KC



On 3/27/06, Tor Lillqvist <tml@...> wrote:
>  > I know that ACE/TAO is already MinGW compliant and builds with
>  > MSYS/MinGW.  This isn't to say that ORBit2 isn't; I don't know that.
>
> Sure, ORBit2 builds with MinGW. In fact, on Win32 it *only* builds
> with MinGW, not MSVC... The reason for this is that the code produced
> by the ORBit2 IDL compiler requires features that only the GNU
> linker's --enable-runtime-pseudo-reloc offers on Win32... I suspect
> ORBit2 wasn't really designed with portability to Win32 and other
> non-ELF platforms in mind.
>
> --tml
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

You'll find one one sourceforge:
http://sourceforge.net/projects/evolution-win32
They have a binary package of orbit 2.12.

HTH
/michael.

KC wrote:
> Hi Tor,
>
> Do you know any binary distribution of ORBit2-MinGW exist ?
> Re-compile ORBit2 under MinGW is not easy because
> ORBit2 depends on pkconfig, glib, linc (maybe), libIDL ....
> None of these have binary distribution could be found
> on MinGW's web site.
>
> Regards
> KC
>

KC writes:
 > Do you know any binary distribution of ORBit2-MinGW exist ?

Sure, check http://ftp.gnome.org/pub/GNOME/platform/2.14/2.14.0/win32/
. There are two ORBit2 zipfiles, the runtime (containing DLLs) and the
developer packages (containing headers, import libraries, .pc files,
documentation, auxiliary tools).

The runtime depends on GLib and libIDL in the same folder. GLib
depends on gettext and libiconv which are in the dependencies
subfolder.

--tml

Michael Bester writes:
 > You'll find one one sourceforge:
 > http://sourceforge.net/projects/evolution-win32

Please don't use that site. It's incomplete and abandoned, at least as
far as the files section is concerned. The real up-to-date versions of
GNOME platform libraries ported to Win32 are on the normal GNOME ftp
server and its mirrors.

I'll try to hide the files at the sourceforge site...

--tml

Hi Tor,

That's GREAT HELP.  Thanks a lot.
Hopefully I can stick on ORBit2 and don't need to
move to TAO or omniORB (I'm kind of die hard C
programmer ^.*)

KC

On 3/28/06, Tor Lillqvist <tml@...> wrote:
> KC writes:
>  > Do you know any binary distribution of ORBit2-MinGW exist ?
>
> Sure, check http://ftp.gnome.org/pub/GNOME/platform/2.14/2.14.0/win32/
> . There are two ORBit2 zipfiles, the runtime (containing DLLs) and the
> developer packages (containing headers, import libraries, .pc files,
> documentation, auxiliary tools).
>
> The runtime depends on GLib and libIDL in the same folder. GLib
> depends on gettext and libiconv which are in the dependencies
> subfolder.
>
> --tml
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>