Mail Archives: cygwin/2010/07/07/20:14:23
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 -