On Thu, Sep 06, 2007 at 12:08:10PM -0500, Tony J. White wrote: > > Why was the name 'i586-mingw32msvc' choosen?
To indicate the target binaries for this build use the msvcrt runtime. > To me this implies that this build was compiled with Microsoft > Visual C Compiler. I'm very much assuming it was not. Until it can create linux targetted binaries, and be included in the distro, it should be fairly safe to assume that remains a clear impossibility, yes ;-) > The (official?) mingw cross-compiler build scripts by Keith Marshall use > 'i386-mingw32' and this is statically defined in the build scripts. I don't think Keith was around when the msvcrt runtime was new and shiny and the crtdll runtime was old and reliable, and people needed the ability to choose for themselves. I've never seen Keith's scripts, but I'm pretty sure these packages pre-date them by more years than I'd care to remember... I can understand that he dropped the msvct/crtdll distinction, since mingw itself dropped support for crtdll quite some time back now, but using i386 for the target cpu would seem to indicate someone didn't put a whole lot of thought into choosing that target designation very carefully... > The README > states that the resulting cross compiler should be invoked as > 'i386-mingw32-gcc', > but it does also create a directory full of binary stubs for gcc, ld, ar, etc. > as this original bug report suggests doing. And does it suggest there are good reasons for the latter? I'm still yet to see any that don't boil down to "work-around broken build scripts in other packages" -- and it seems totally wrong and unproductive to me to encourage the proliferation of broken build scripts and bad habits. > I do a bit of cross compiling using mingw and I find it quite annoying at > the scattered naming conventions that different distros use. *shrug* there were no other distro's providing this when the naming conventions in this package were established. It was even discussed on the mingw lists IIRC. I can't help others not following suit. I'd surely get more hate mail from long time users if I gratuitously changed the name now, than I get from people who want to hard code things that they shouldn't. If you really care about unified naming, you're going to need to get all the affected parties together and come up with a plan to transition. And then spend the next few years chasing everyone who didn't get the memo. > As a comprimise, why not just create symbolic links with some more standard > names? For example: mingw32-gcc would be a symlink to i586-mingw32msvc-gcc or > whatever wonky prefix of choice is. Sorry, but I don't see that as a compromise, or even related to the original request. Hardcoding extra wonky prefixes, for cpu's that neither Debian nor Billware support any more, so that build scripts can be even _more_ broken, frankly seems quite insane. The only thing this could possibly help with is spreading confusion and Bad Practice. If your build scripts can't handle any triplet that you might have a toolchain for, from s390-mingw32crtdll to arm-linux-uclibc, then they don't support cross compiling. When they do, you won't need all this extra goop, or feel the need to be annoyed at the number of possible cross permutations. There are more of them than you'll ever want to hardcode. (More) standard naming conventions for this sort of thing would be lovely to have, but more names for the same toolchain on a single system is an idea that should send a chill down your spine. I've yet to see a real problem that had no other solution than this, so in the absence of that, this kludge seems pretty hard to justify... and the more time that goes by, the more of a kludge it appears to be. YMMV, but I need real evidence of that before I'll be convinced that messing with PATH is somehow a good thing to do for cross builds, even without using a different name to the rest of the toolchain. Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
