On 23/02/2011 13:13, M. Andree wrote: > Am 22.02.2011 09:40, schrieb David Brown: > >> There is no doubt that it is easier to build a cross-gcc using cygwin >> rather than mingw. This is because cygwin has a very thick interface >> layer between the programs and the underlying Windows API, so that >> cygwin programs see a very Linux-like environment. For example, >> programs can use fork, filesystem links, etc., which non-cygwin programs >> cannot do on windows. Thus there are also far more Linux-style >> utilities for cygwin. > > This isn't true. NTFS supports native hard links, for instance, and > MinGW just builds the adaption layer into the executables, where Cygwin > keeps it separate, and separately upgradable. Of course the results are > limited to what the interface layer (MinGW or Cygwin) offers, and MinGW > offers fewer features thatn Cygwin does. >
NTFS only sort-of supports hard links - you can use them, but you will quickly confuse other windows programs (including Explorer). It's like support for having multiple files in a directory that differ only by the letter cases. It's a feature that was put into NTFS so that MS could tell businesses "NTFS has support for posix - you can easily migrate your UNIX software to Windows NT". As soon as businesses got hooked on Windows NT, most of the pretence of posix compliance was dropped. Cygwin builds up a layer to provide as full posix compliance as possible. MinGW just provides a thin translation layer to map posix concepts to windows concepts - if there is no matching concept in windows, then the function is not implemented in MinGW. The most obvious example of this is "fork". Windows does not have "fork" functionality - it has only "spawn" (roughly "fork + exec"). So MinGW does not have fork either. Cygwin /does/ have fork - and it is a very costly simulated function. Cygwin's layer is so big and thick that it is normally implemented using dll's, but can be statically linked. MinGW's layer is so small and thin that it is normally statically linked, but can use a dll if you want. >> There is no doubt that it is easier and faster to /use/ software built >> with mingw. This is because mingw does not have the cygwin layer - >> programs feel more "native" on windows, and run faster. > > Well, somewhat. Easier to use depends on which way you want to go. If > you have unixy tools like GCC, then feeling more Windows-like isn't a goal. > A lot of unixy tools like gcc work fine under windows, with a windows-like feel (unless you need a gui to be windows-like). I have used gcc, mingw and msys for many years - being faster is a real advantage over cygwin equivalents, as is the use of slightly more normal paths (rather than having things like "/cygdrive"). If I need real *nix behaviour, I'll use Linux. But when I use Windows, I like to have my command-line utilities as native as possible - cygwin always feels a bit like an alien implant. >> One of the biggest issues with cygwin is the dreaded cygwin1.dll >> problem. Cygwin-generated tools require a number of dlls, and these >> come in many different versions. It's not too bad for programs that run >> for a bit then stop, but if you've got long-running cygwin programs >> (such as an rsync daemon, or a ssh client), it can be a real problem. > > I have yet to see the "dreaded cygwin1.dll problem" in practice. You may > possibly have to add cyggcc* and NLS dlls if you leave NLS enabled, but > that's about it. > The "cygwin1.dll" problem applies to a number of other dll's included with Cygwin, depending on what the application actually uses. The problem occurs when you have more than one cygwin program running at a time, and they attempt to use different cygwin1 dll's (or other dll's). For most windows programs, it isn't a problem that two programs load different versions of the same dll - both get loaded, and they are kept separate. You don't get the advantage of sharing, but both programs work. Cygwin, for some reason (I'm sure it's a good reason - perhaps for implementing IPC), will not allow more than one copy of each dll to be loaded at a time. This means that if you have a program running with one version of cygwin1.dll loaded, and try to start a second program with a different version, it will fail. The way around this is to have only one copy of cygwin1.dll on your system, and make sure it is on the path - then all cygwin-compiled programs will use it. The trouble is that many cygwin-compiled programs come packaged with their own copies of the dlls - you have to root them out and delete or rename them. And while most programs can work with newer versions of the dll, so that you just need to keep a single version updated, there have been incompatible changes over the years - some programs need older versions of the dll. And then you have some tools (such as FPGA development suites that I have used) that like to have their own fairly complete private cygwin installation that will quickly conflict with other running cygwin-compiled software. /You/ might have avoided all this, but I have seen all these issues. I am sure that there are many more such problems that others have had. It varies very much according to the way you use your machine - for example, I have cygwin rsyncd running as a service, which means I always have at least one cygwin-compiled program running. > To me, the "dreaded cygwin1.dll problem" is either a myth, or a phantom, > or a severely botched installation, and the WASP project stuff for one > works well with Cygwin but requires heaps of hacks for MinGW/MSYS > builds, and isn't feature complete. So. > There are certainly times when Cygwin makes porting from *nix far easier - I am in no way saying that Cygwin is not useful. I am just saying that if MinGW will do the job, it is usually the best choice. > None of the persons speaking about this "dreaded cygwin1.dll problem" > has so far been able to provide me with a reproducible "cygwin1.dll > problem" that wasn't in itself an administrative problem, and I have yet > to see a situation where I would be required to load two different > cygwin1.dll versions at the same time. > Well, if by "administrative problem" you mean it can be fixed by an appropriate amount of deleting extra cygwin dll's, updating a single common copy, getting paths correct, etc., then yes, "cygwin1.dll" problems are almost always "administrative" problems. But they are still a pain and a waste of time and effort for someone who knows what they are doing - and much worse for people who don't know what is going on. >> And if you want maximum geek points, try a Canadian Cross - use 64-bit >> Linux to build a 32-bit mingw-hosted compiler for the 16-bit msp430 :-) > > I know that WSim is cross-built on Linux, for one - and thus didn't > expose libsdl issues (now resolved through use of system-native > interfaces), but anyways. > ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
