X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.1 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_JL,TW_YG
X-Spam-Check-By: sourceware.org
Message-ID: <4C3534E6.90505@cwilson.fastmail.fm>
Date: Wed, 07 Jul 2010 22:16:06 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Cygwin Mailing List <cygwin AT cygwin DOT com>
Subject: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
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> <1278548055 DOT 6960 DOT 59 DOT camel AT YAAKOV04>
In-Reply-To: <1278548055.6960.59.camel@YAAKOV04>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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 7/7/2010 8:14 PM, Yaakov (Cygwin/X) wrote:
> 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.

Hmm. That's what I *was* doing: JonY's -src provides a cygport that
appears to work.  You have to impose some workarounds, like:

RESTRICT=strip

and manually use the target strip tool within src_install, but...it
*works*.  (E.g. how much 'in-elegance' do you want to put up with).

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

Yeah, I know.

> 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.

Honestly, I just don't get this.  Are you participating in a live
#mingw-w64 session, or looking at old logs?

The mingw64-gcc I *just built* /is/ multilib, and I generated all the
necessary packages including two versions of all the language runtimes.
Using cygport (with the two tiny patches you don't like, but that's not
a reflection on *gcc*'s multilib support).

So, it *does* build.  Whether the packages so generated, once actually
installed by setup.exe, WORK properly, I haven't yet tested.  But that's
not what you were saying: that multilib didn't "work".  You said it
doesn't "build" -- but JonY and I both built it.

Hence my confusion.

>> 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.

I agree (willing to be persuaded that all three compilers could be
NON-multilib, but it seems JonY *wants* to provide multilib -- I guess
for just the default-to-64bit compiler -- and I'm not gonna stand in his
way, if he'd doing the work.

>> Well, to an extent I agree. But...what if you're building a 
>> cross-compiled package (say, mingw-xz, with liblzma), and installing 
...
> 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.

I disagree, but will expand below.

>> 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.

Right, bad example.  libobjc, then.  Again, I disagree, but will expand
below.

>> 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.

True that.

>> 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?

But the difference is, we are NOT actually talking about two completely
separate platforms.  You CAN run mingw apps and use mingw DLLs from
"cygwin" directly (mingw64-32, or mingw.org), because it's running on
top of plain old windows.  Ditto mingw64-64 -- assuming you're on a
64bit Windows.

And...libtool already makes allowances for this: that's why cygwin
specifically uses the 'cyg' prefix for all DLLs, so they won't conflict
with mingw libs that could be in use simultaneously on the same machine (*).

So, your analogy is not completely representative of the cygwin|mingw
situation.

I would REALLY like to be able to set $PATH to include
/usr/sysroot/mingw32/bin and test (for example) mingw-bzip2.exe WITHOUT
having to go manually copy
   /usr/sysroot/mingw32/lib/libbz2_2.dll,
   /usr/lib/gcc/i686-pc-mingw32/4.6.0/libgcc_s-1.dll
to /usr/sysroot/mingw32/bin/ before I can!  (And then, have to remember
to redo that every time something gets updated in its "proper" buried
location).


(*) The mingw64 guys wanted to patch libtool to use a different prefix
also for 64bit (lib64_? ick), so that 32bit and 64bit DLLs from the same
package could also coexist but the patch was rejected, IIUC.  I don't
remember that discussion and haven't tried to research the conversation.

> 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.

Again, ONLY if you shackle Dave Korn and JonY together at the hip, and
require that all compiler versions, for any $target, remain in lockstep
forever.  I don't think that is fair to either maintainer.  (Or to John
Doe, if he steps forward to provide a $target=linux cross compiler).



If /opt is completely unacceptable, then I'd prefer allowing the cross
toolchains to use $target-specific --datarootdirs.

   /usr/bin/$target-foo.exe
   /usr/$target/{bin,include,lib}
   /usr/$target/share/{info,man,locale} <<<--- datarootdir
   /usr/lib/gcc/$target/$version

Although the *cygwin* specific docs would still go in
   /usr/share/doc/Cygwin/*
and maybe
   /usr/share/doc/$pkg/
but perhaps that last one also belongs over in the 'new' datarootdir.

Short of that, then just stripping out all docs, and compiling with
--disable-nls, like fedora does, is better than forcing JonY and DaveK
to coordinate so closely in perpetuity.


Given the analysis of fedora, and Corinna's tentative interest, support
for, in addition to the tree discribed above, having also a separate

   /usr/sysroot/$target-shortname/{bin,lib,include,share,...}

tree for pkgs-compiled-using-the-cross-compiler (e.g. you'd use
--prefix=/usr/sysroot/$target-shortname explicitly -- or automatically
depending on how smart cross-client.cygclass is) is something I think
you should consider.  At *least* for client packages like mingw-zlib,
etc, even if this "pseudo-sysroot" is relatively disconnected from how
the cross-gcc itself is configured and installed.

> 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.

Ah-HA!  And THAT's why you used a not-entirely-appropriate analogy
above.  If your generic cross.cygclass did stuff like move .dll's
around, then when used for i686-pc-linux-gnu, it would move .so's around
and that would be inappropriate.

But...I assert that if $host=cygwin, then $target=some-mingw-variant is
*special* in a way that other $targets are not.

what about this:

mingw64-tc64-gcc.cygport:
...
inherit cross
inherit mingw-cross
...

where mingw-cross.cygclass extends the generic cross support to do some
of the *special* things that are appropriate to a mingw-$target cross
compiler on cygwin-$host?

like moving dll's to places other than where libtool wants to put them
by default, AND different than where .so's would go on linux...

[snip]
> 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.

Waiting with bated breath!

--
Chuck

--
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