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_JL,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:	<4C34D3BF.7020404@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> <1278519024 DOT 1096 DOT 90 DOT camel AT YAAKOV04> <4C34D3BF DOT 7020404 AT cwilson DOT fastmail DOT fm>
Date:	Wed, 07 Jul 2010 19:14:15 -0500
Message-ID:	<1278548055.6960.59.camel@YAAKOV04>
Mime-Version:	1.0
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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 Wed, 2010-07-07 at 15:21 -0400, Charles Wilson wrote:
> Really?  Other than the packaging issues, I had no problem with JonY's 
> src snapshot, compiling a 64bit-default, but multilib enabled, gcc.  did 
> something break upstream between when JonY took his snapshot and today, 
> or are you referring to some other problem?

I meant with cygport: strip(1)ing, cygconf handling of
--build/host/target, definition of $CC and friends, dependency listings,
and more.  There are a lot of cygwin-cygwin-cygwin assumptions in the
code that need to be revised, but I'm making progress.

As for the packaging, I don't agree with the current packaging, but I'll
save my opinion for my response to his ITP.

> It is...tricky, no doubt.  But all problems have solutions...depending 
> on how much effort and/or how much in-elegance you're willing to put up 
> with. <g>
> 
> And, of course, whether the benefits outweigh those costs. Since JonY's 
> doing the work, I'm willing to defer to his judgment on that once all 
> the costs are documented on the list and he can make an informed decision.

OOTB gcc multilib does not build, nor AFAICS do clear-cut patches exist
to fix it.  Others in #mingw-w64 seem to think that multilib isn't worth
the headache, at least not yet.  We'll see what I come up with over the
next few days, but right now I'm going with a non-multilib gcc as my
working example.

> Am I correct in supposing you'd favor two mingw64 compilers:
> 
>     64bit default, multilib (because "multilib makes sense for a 64bit 
> compiler") based on mingw64
> 
> PLUS a
> 
>     32bit *non-multilib* mingw64 compiler (because "[multilib] makes no 
> sense for a 32bit compiler", and "there is a place for both [mingw64 
> 32bit and mingw.org 32bit, as I read your statement in context]")
> 
> and a separate
> 
>     32bit mingw.org compiler ("there is a place for both")

Yes, I believe that there is place for all three of those.

> Well, to an extent I agree. But...what if you're building a 
> cross-compiled package (say, mingw-xz, with liblzma), and installing 
> into a sysroot (e.g. --prefix=/something/other/than/usr:
>     /usr/sysroot/mingw32/lib/liblzma.la
> In that case, wouldn't the corresponding DLL go into
>     /usr/sysroot/mingw32/bin/liblzma-0.dll
> That is, ../bin ?

That would be libtool's default, but that doesn't make it right.  My
changes to the libtool fixups would move it back into lib.

> Or, are you talking only and specifically about the DLLs associated with 
> the gcc runtime libraries, like libgcc_s-sjlj-1.dll?

Remember that libgcc is not a libtool library.  But the other gcc libs
are, and I would also leave them alongside their .la's.

> Wonderful, and I appreciate that very much. This (and the entire cluster 
> of related) discussion have a great potential to turn into bikeshedding 
> confabs, so contributions by folks who, like yourself, are actually 
> rolling up their sleeves and pitching in are MUCH appreciated.
> 
> Thank you.

You're welcome.  I knew this was a deficiency in cygport for a long
time, but I needed someone to give me something concrete to work with.

> Ah, but before they can be fixed, you must determine what the correct 
> behavior should BE.  I don't think leaving dll's -- particularly for 
> cross-compilED packages (aka (1), above) -- in the same directory as the 
> .la is the right thing to do.  For the compiler's $target runtime 
> DLLs...I don't know. Certainly they do not belong in /usr/bin, whatever 
> happens.  Where they SHOULD go -- I don't think we've determined that yet.

My POV is that a cygwin-hosted mingw*-target compiler is no different
than any other cross-compiler: nothing on the system is meant to *run*
with the $target libraries, because in 99% of cross-compiles that's
impossible.  Therefore, they don't need to be in PATH (or in a place
which is conveniently added to PATH).

As you say, they obviously don't belong in /usr/bin (they're not needed
there, and the three mingw* would collide), nor in /usr/$target/bin (not
its purpose).  The only place that does make sense is alongside the .la,
just as it would be with with other cross-compilers.  You wouldn't move
a cross-compiler libgcc_s.so.1 to /usr/lib or put its toolexeclibdir in
LD_LIBRARY_PATH, would you?

So right now my approach
is /usr/bin/$target-foo.exe, /usr/$target/{bin,include,lib}
and /usr/lib/gcc/$target/$version, with conflicting data (e.g. infos and
locales) removed, as the latter could be shared by the native
binutils/gcc.

> However, if additional cygport changes are planned and ongoing to make 
> this cross stuff work better -- than I shall now do the Snoopy Dance of Joy.

I'm not limiting this to mingw32/64; my intent is to make a generic
solution that will work for *any* target.  I plan to test with a
i686-pc-linux-gnu toolchain as well, time permitting.

> I *DO* wish that somebody had chimed in to the discussion earlier, 
> before JonY and I had progressed very far along.  My original 
> suggestions -- most of them, anyway -- were intended to start 
> discussions, not necessarily be taken as immediate instructions for 
> JonY.  However, he did act on them almost immediately -- and nobody 
> complained. So, we kept going.
> 
> Now we have a lot of track to retrace. I feel bad for JonY.  Maybe we @ 
> cygwin and cygwin-apps can get this all nailed down for him, before he 
> returns next week.

I intend on doing just that, with a response to his ITP containing a
beta cygport(1) and a complete set of revised .cygports to match.  Stay
tuned.


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

- Raw text -