Hi, Ian and others, I don't want to start a discussion about Cygwin and MinGW tools, but just to clarifiy some aspects...
Ian MacArthur wrote: > Don't get me wrong, I'm a big fan of the mingw tools. > But I use them native on XP/Vista, rather than using them to > cross-compile from my linux boxes. [ Scott A Thisse wrote: ] >> I found the setup easiest with Cygwin, which includes the MinGW tools. >> Since I'm usually not concerned with space on my desktops, I just >> install everything. An added benefit is that I also get all the usual >> collection of indispensable command line and X Win tools. > > I gave up on cygwin some years back - we had some serious performance > issues with some code, and the same code compiled "native" with mingw > was substantialy faster. Here you must distinguish between using cygwin for development and compiling and linking "cygwin" applications. Like Scott I do also use cygwin for development, but I always use the -mno-cygwin compiler option to produce native Windows applications (and FLTK configure does this by default, you would have to enable the cygwin version explicitly with --enable-cygwin). As I wrote earlier, this effectively uses the included MinGW compiler tools and produces native Windows applications w/o cygwin dll dependencies. This way I can install all cygwin tools like subversion, X server, all commandline tools I'm used to in my Linux environment, and so on. I don't know what MSYS would provide, but surely not as much as the cygwin tools do. If you had runtime problems, then you must have used the cygwin compiler, and then you had cygwin1.dll dependencies. That's why I never considered using this at all. > We also had a few other third-party tools installed that used cygwin and > things degenerated into dll-hell for a bit, with variant cygwin and > cygwin1 dlls all over the shop, all messing each other up. Well, that's a mess, really. If you need to use third party tools whose developers insist on providing their own cygwin dll, then you _have_ problems. Different versions of cygwin1.dll can't coexist (at least not, if you activate more than one program with different dll versions concurrently). But this is the 3rd party tool provider's problem - they should always use the installed version, and if they need a newer version, ask you to install at least this one. But if they don't, then you as a user are hosed. > That said, I'm assured it all got a lot better since then, but I find > the native mingw tools with Msys are perfectly adequate, and without the > dll issues... The dll problem didn't change until now, although the upcoming version 1.7 will have another cygwin1.dll that _can_ coexist with the older 1.5 dll, but probably not with another version of the new 1.7 generation. That said, I'm using cygwin without having many problems, but from time to time upgrading the tools can bring some problems (e.g. the recent switch to a new X server version, and probably soon the upgrade to 1.7 and gcc 4.x), but new compiler versions will also be in MinGW. BTW.: the new gcc version will replace the -mno-cygwin option with another one that is more like a cross compiler option, something like --target=i386-...mingw...-??? (I don't know what exactly it will be). We'll have to check this in our configure script. Of course, YMMV. Cheers Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
