This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] mingw-w64

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

> 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.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]