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


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