On 7/3/2010 2:28 AM, Andy Koppe wrote: > On 3 July 2010 03:07, Charles Wilson wrote: >>> Is mingw64 already part of a major Linux distribution? Otherwise it >>> needs five votes from Cygwin maintainers. >> >> AFAICT, mingw64 is "the" mingw cross compiler provided by fedora. > > Great. > >>> Finally, I'm not sure what the conclusion was about which toolchain(s) >>> will be included. Looks like a single multilib toolchain defaulting to >>> 64 bits to me. If that's the case, is the "tc64" bit in the name >>> actually needed? >> >> IMO, even if JonY has no *immediate* plans for a default-to-32bit >> toolchain (whether multilib or single target), I think it makes sense to >> allow for the possibility in the package naming scheme. >> >> And...JonY already said he was "saving" the /i686-w64-mingw32/* tree for >> use by "the" default-to-32bit toolchain, so... > > 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. But I'm not saying that I can't deal with it the other way around. Or with installing two separate single-target compilers. However, the mingw64 project is mostly concerned with 64bit support, so "they" probably WANT to provide a default-to-64bit compiler, since that's their bread and butter. 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. > Is it worth > the extra packaging effort, and, more importantly, the extra scope for > user confusion (particularly once the original MinGW is thrown into > the mix as well)? I think we WILL need a new section in the FAQ. But I think that will be true regardless of how we "solve" this conundrum. Cross compilers are complex pieces of software, and newbies WILL have questions. And multilib is odd, even on linux. > Regarding the placement in /opt/mingw64, how do the Linux > distributions deal with the problems that lead to that decision? I > think this needs to be considered carefully because it sets a > precedent for any other cross-compiler packages. 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." 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. -- Chuck