On 3 July 2010 14:37, Charles Wilson wrote: >> What's the use case for having two multilib toolchains instead of >> either two standalone ones or a single multilib toolchain? > > My use case is: I'd like to install one compiler that handles both > "targets". But, since my personal PCs are all 32bit, I'd rather that > compiler default to 32bit, and only create 64bit binaries on demand. > > E.g. it feels "odd" to me to ROUTINELY have to say > --host=x86_64-w64-mingw32 CFLAGS="-m32" > when I really want i686-w64-mingw32 > > But if, every once in a while, I have to say > --host=i686-w64-mingw32 CFLAGS="-m64" > that's ok.
Fair enough. > PERHAPS it makes the most sense to provide two single-target compilers > (but most of the interop issues would remain; the only simplification > would be the elimination of any packages that are explicitly > "mingw64-{tc64}-m32-foo" or "mingw64-{tc64}-m64-foo", in favor of one > that is just "mingw64-tc64-foo". > > OTOH, I understand the mingw64 guys want to ensure that the multilib > support they've added to gcc/w32 stays in good working order, so they > probably prefer to provide multilib regardless of any minor packaging > confusion. I'd be termpted to go with two single-target compilers, but as long as the mingw64 guys are happy to deal with two multilib ones long term, I guess that's ok. > Most of the cross toolchains I've installed or used either install into > their owntree, OR are provided as patched source code and the > instructions include building them yourself -- again, installing into > their own tree. I'm not familiar with very many pre-packaged cross > toolchains that attempt to go directly into /usr. > > One exception appears to be Fedora's mingw cross compiler. The > *compiler* appears to be compiled with --prefix=/usr with a sysroot. > Most of their build guidelines concern creating "mingw" packages for > OTHER things than the toolchain itself -- and in THOSE cases, they do > use a separate _mingw_prefix. But, those guidelines also include > statements like "In general terms, MinGW packages which provide > cross-compiled versions of packages already natively available in > Fedora, should follow the native Fedora package as closely as possible. > This means they should stay at the same version, include all the same > patches as the native Fedora package, and be built with the same > configuration options." Hmm, yeah, that last bit isn't realistic for Cygwin. > If the same statement holds true for the compiler itself, then maybe > they either (a) just don't package the share/locale/*/ files and info > files for the cross compiler because it'll always be kept (track) the > same version as the platform compiler. OR (b) they just don't enable > i18n for the mingw cross compiler. Ditto info files? Man pages -- most > of them, anyway -- appear to automatically be renamed with $host- prefixing. > > But... > > While we should probably take hints from other platforms, cygwin is not > linux. If we have different predicates -- and we do -- then we will > reach different conclusions. And that's ok. Of course, but diverging does increase the likelihood of complaints. Yet if it can't be done the "standard" way, I guess we'll just have to deal with it. One thing that might come up in this context is that C:\cygwin\bin will need to be in the PATH when invoking the compilers from Windows programs, e.g. Eclipse. Thanks to JonY and yourself for putting all this work in. Andy