This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
- From: Andy Koppe <andy dot koppe at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 11 Jul 2010 20:04:48 +0100
- Subject: Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
- References: <4C3215FC.3010309@cwilson.fastmail.fm> <1278402537.5784.8.camel@YAAKOV04> <4C337C6E.2080003@cwilson.fastmail.fm> <1278455320.4032.49.camel@YAAKOV04> <4C33EEC1.9050600@cwilson.fastmail.fm> <1278519024.1096.90.camel@YAAKOV04> <4C34D3BF.7020404@cwilson.fastmail.fm> <1278548055.6960.59.camel@YAAKOV04> <4C3534E6.90505@cwilson.fastmail.fm> <1278560355.6960.114.camel@YAAKOV04> <4C35E1E1.1080906@cwilson.fastmail.fm> <1278724102.7240.61.camel@YAAKOV04> <4C3A10CA.30606@cwilson.fastmail.fm>
On 11 July 2010 19:43, Charles Wilson wrote:
> On 7/9/2010 9:08 PM, Yaakov (Cygwin/X) wrote:
>> On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
>>> Now, his ORIGINAL proposal was 64bit only, non-multilib. ÂMaybe he'd be
>>> pleased to go back to that; my feeling is he'd rather do multilib if
>>> possible, but I'm not sure, and certainly don't speak for him.
>>
>> Right now I'm working with non-multilib, both i686 and x86_64. ÂIt's a
>> lot cleaner that way -- especially when it comes to cross-compiling
>> other packages, doing so in a simultaneous multilib fashion would
>> require even more drastic changes to cygport.
>
> Hmm.
>
> How about this: suppose for the sake of argument that JonY *really*
> would rather the 64bit compiler, at least, also support multilib -- in
> the long run.
>
> However, it's easier to walk before you run, so how about we get
> everything nice and pretty with two (three, counting mingw.org) separate
> non-multilib tool chains.
Sounds good. May JonY's maintainership be long and prosperous, but
maintainers do come and go, so if even NightStrike isn't convinced of
the need for multilib, it's better to avoid the extra complexity to
make things easier for any future maintainers.
Andy