On Jun 11 16:52, LRN wrote: > > And why exactly is that a problem? The cross compiler is creating > > the exact same code as a native-like compile with the same version. > Cross-compiling is somewhat more tricky. Also do remember that MSYS1 is > rather old, cross-compiling was even trickier back then. And Cygwin had > - -mno-cygwin for that purpose back then too. > > AFAIU, it's also tricky to run testsuite when cross-compiling.
I'm using the Mingw cross compiler as part of the Cygwin distro a lot for testing purposes. I never had much of a problem. And the -mno-cygwin flag was a hack. I admit freely that I was kind of nervous when everybody around me thought it's a good idea to remove that flag, but I'm certainly not looking back anymore for a long time. > >> it should be obvious that crude > >> symlink-by-copying is necessary to satisfy W32 tools, which cannot use > >> cygwin symlinks or Windows .lnk files. > > > > Not really. If you need a copy, call cp. That's what it is for. > > Faking symlinks by copying is just bad. So you create a symlink by > > copying. Next you change the original. The consumers of the symlink > > will never see this change. This is just... bad. > Indeed, users are able to call cp instead of ln. Buildscripts can't. > Buildscripts (which mostly means autotools) are written with the > assumption that they will be run on a POSIX system, and thus MSYS has to > provide POSIX tools. Just as Cygwin does. Except that Cygwin goes all > the way down to the toolchain and compiles Cygwin programs, while MSYS > stops early, only providing tools (i.e. things that are only used at > build-time), and only those tools that can't be feasibly ported to W32 > (i.e. pkg-config and gettext are ported, bison and bash are not; libtool > is a borderline case - is a shell script, but it is also very W32-aware). And what's the exact problem here? If you have a POSIX toolset anyway, it can be easily used from autotools. Why *do* you stop in the middle? The fact that autotools use POSIX tools doesn't mean the end result of your build has to. > I do understand that Cygwin improved a lot since MSYS1 fork, and that > cross-compiling also moved on, so cross-compiling from Cygwin is not as > scary as it was years ago (i hope it isn't; i don't use Cygwin, and i > don't cross-compile on my Debian machine these days, so that's all just > speculation on my part). Cross-compiling is dead easy these days. For instance, I'm building the Cygwin package and multiple other packages on Linux for years. Yes, there are packages which refuse to configure correctly when trying to cross-build them, but these are simple bugs in the autoconf script, which are rectifiable and, ideally, sent upstream. > Still, i'm not convinced that Cygwin is the > universal, all-purpose tool that you seem to think it is > (SquarePegRoundCygwin). Dunno about that. It seems to me that the peg is only square because it has been mauled with too big a hammer. Creating an incompatible POSIX toolchain with a forked DLL which in principal only differs by name is such a big hammer. Creating a simplified set of tools but using the same underlying DLL without introducing incompatibilites would have been the more friendly way, IMHO, for the developers and the users. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
