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.

Andy


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