X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-50.8 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_YG
X-Spam-Check-By: sourceware.org
Subject: Re: cygport patch: suppress libtool fixup step
From: "Yaakov (Cygwin/X)" <yselkowitz AT users DOT sourceforge DOT net>
To: cygwin <cygwin AT cygwin DOT com>
In-Reply-To: <4C33EEC1.9050600@cwilson.fastmail.fm>
References: <4C3215FC DOT 3010309 AT cwilson DOT fastmail DOT fm>	 <1278402537 DOT 5784 DOT 8 DOT camel AT YAAKOV04>  <4C337C6E DOT 2080003 AT cwilson DOT fastmail DOT fm>	 <1278455320 DOT 4032 DOT 49 DOT camel AT YAAKOV04>  <4C33EEC1 DOT 9050600 AT cwilson DOT fastmail DOT fm>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 07 Jul 2010 11:10:24 -0500
Message-ID: <1278519024.1096.90.camel@YAAKOV04>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Tue, 2010-07-06 at 23:04 -0400, Charles Wilson wrote:
[massive snip]
> OK, so the next question is, if they going to go multilib, why provide
> TWO different toolchains -- basically identical, both supporting both
> -m32 and -m64, different only in the default bitmode?
> 
> Well...that's up to them.  Me, I'd be happy with either (A) two separate
> non multilib compilers, or (B) one multilib compiler that defaults to 64
> bit, or (C) one multilib compiler that defaults to 32 bit (although that
> last one is probably unlikely, as the mingw64 guys' raison d'etre is
> 64bit support).

Multilib has its place -- for a native 64bit compiler.  A i686 multilib
IMO makes *no* sense.  For a cross-compiler, I agree that separate
non-multilib i686-w64-mingw32 and x86_64-w64-mingw32 compilers would be
practical.  Besides, right now multilib gcc won't build, although
supposedly a patch exists for that.  But from the packaging perspective
multilib is just a nightmare.

> But, see above; because the mingw64 and mingw.org compilers (esp. w32api
> and runtime environments) are *different*, I think having two different
> flavors helps. Diversity is good -- as long as we are careful to ensure
> that the suites do not interfere with each other, and can be installed
> simultaneously.

Yes, I understand the differences now and agree that there is place for
both.

> > Then I will proceed in that fashion for *-*-mingw* hosted DLLs, and skip
> > them for other hosts.
> 
> Err...both mingw.org and mingw64 match that triple:
> 
>    i686-pc-mingw32    : mingw.org 32bit
>    x86_64-w64-mingw32 : mingw64 64bit
>    i686-w64-mingw32   : mingw64 32bit
> 
> Was that intentional on your part, or were you attempting to indicate
> different behavior for the two mingwish variants?

Yes, that was intentional.  Anything that's not Cygwin-native doesn't
IMO belong in Cygwin $PATH, and leaving the ../bin makes no sense
either.  All non-Cygwin PE hosts are alike in that sense.

> I attempted to explain the need here; apparently my communication skills
> are insufficient to the task.  Please download and attempt to rebuild
> mingw64 gcc using a non-patched cygport, and provide your suggestions
> for how JonY can address the packaging failures that occur, since mine
> are unsatisfactory.

In fact, I'm doing just that.  I told JonY from the very beginning --
before the ITP -- that cygport needed work to support
cross-compilers/ing, and I was willing to fix it but I needed concrete
examples.  I have them now, I am building them, and from that I'm
working on exactly how to make the extensive changes necessary to make
this case work.  There is much more involved here than libtool fixups.

> "No, your proposed way is wrong" with nothing further is...unhelpful.

I never said that.  I *did* say that this was not a case for *disabling*
libtool fixups but for *fixing* them, which I am doing.  David's libao
case was an upstream bug -- the layout was wrong with or without libtool
fixups.  And obviously we don't want them for non-PE hosts, but that
will also be fixed within cygport itself.  So my stand by my statement:
I have yet to see a single legitimate case for not using libtool fixups
for PE hosts.  Feel free to try to prove me wrong with actual cases.


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple