From: KC <kc...@gm...> - 2006-03-27 03:43:12
|
Hi, Couple questions: 1) Does Cygwin + --no-cygwin =3D MinGW ? and generate native windows code ? 2) There is a gcc-mingw package in Cygwin distribution. Is that the same one which I found in www.mingw.org ? What's the different ? 3) Does library created by Cygwin can be used directly under MinGW ? Thanks Regards KC |
From: KC <kc...@gm...> - 2006-03-27 17:10:45
|
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 <tm...@ik...> 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 > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Tor L. <tm...@ik...> - 2006-03-27 20:20:30
|
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 |
From: Michael B. <mic...@gm...> - 2006-03-27 19:03:03
|
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 > |
From: Tor L. <tm...@ik...> - 2006-03-27 20:29:08
|
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 |
From: KC <kc...@gm...> - 2006-03-28 04:16:55
|
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 <tm...@ik...> 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 > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Michael G. <mg...@te...> - 2006-03-27 04:35:15
|
> 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 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 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: mg...@te... GPG-keys available on request or at public keyserver |
From: Brian D. <br...@de...> - 2006-03-27 04:47:09
|
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 > 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 |
From: KC <kc...@gm...> - 2006-03-27 05:08:46
|
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 > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Brian D. <br...@de...> - 2006-03-27 05:36:08
|
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 |
From: KC <kc...@gm...> - 2006-03-27 05:58:28
|
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 <br...@de...> 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 > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Daniel J R. <ell...@te...> - 2006-03-27 06:38:20
|
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: min...@li... [mailto:min...@li...] En nombre de KC Enviado el: lun, 27 de marzo de 2006 07:58 Para: min...@li... 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 <br...@de...> 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 > Min...@li... > > 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 Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Earnie B. <ea...@us...> - 2006-03-27 13:13:39
|
Quoting KC <kc...@gm...>: > 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 |
From: Tor L. <tm...@ik...> - 2006-03-27 15:44:53
|
> 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 |
From: Tor L. <tm...@ik...> - 2006-03-27 06:05:31
|
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 |
From: Michael G. <mg...@te...> - 2006-03-27 05:37:07
|
> 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: mg...@te... GPG-keys available on request or at public keyserver |