Message-ID: <4C34D3BF.7020404@cwilson.fastmail.fm>
Date: Wed, 07 Jul 2010 15:21:35 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: 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>
In-Reply-To: <1278519024.1096.90.camel@YAAKOV04>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 7/7/2010 12:10 PM, Yaakov (Cygwin/X) wrote:
> 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,

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?

> although
> supposedly a patch exists for that.  But from the packaging perspective
> multilib is just a nightmare.

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.

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

Ack.  I'll probably have to repeat a lot of that information over in the 
other cygwin-apps thread, since Corinna just asked basically the same 
question over there.

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

?

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

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 ?

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

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

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.

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

Certainly true, especially if you are trying to support both (2) and (1) 
immediately (*), initially, and perfectly.  I don't think a perfect 
solution can ever occur at the 1.0 release of new functionality, and 
would rather see "pretty good" sooner, followed by "better and better" 
-- rather than just "perfect" a looooonnnng time from now.

(*) from upthread, (2) = use cygport to package a cross compiler, (1) = 
use cygport + a cross compiler to package cross-compiled packages (aka 
mingw-xz, liblzma).

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

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.

Corinna likes the /usr/sysroot/$target-shortname/{bin,lib,share} 
approach.  If we go that way, then TRTTD IMO is to put the compiler's 
$target runtime DLLs in /usr/sysroot/$target-shortname/bin, while -- as 
usual -- the compiler target runtime .la and static libs would live in 
$prefix/lib/gcc/$target-triple/VERSION/.  (Whether $prefix is /usr, or 
/opt/mingw64/toolchain/ or whatever).

Supposing
    /usr/sysroot/$target-shortname/bin +
    the cross compiler itself going in /usr
then the relative path from the .la to the dll would be...odd.

   ../../../../sysroot/$target-shortname/bin/

> David's libao
> case was an upstream bug -- the layout was wrong with or without libtool
> fixups.

No argument. I never mentioned libao. I'm looking mostly at the 
toolchain itself and its related libs, plus thinking ahead about how we 
handle *existing* mingw packages in the distro (mingw-zlib, etc) -- and 
I'm perfectly willing to recompile/repackage *those* to meet whatever 
new standard we devise.

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

No, I don't *necessarily* disagree. I want it (the toolchain) to *work*. 
How we actually get there -- is open for discussion.  Maybe I missed it, 
but until your message yesterday I did not know you intended to do much 
to assist the 'cross' case at all. (yes, this:
	* cross.cygclass: NEW for cross-compilers and
           cross-compiling; NEEDS WORK.
has been around since 0.2.7, but...it has 'needed work' for a long time).

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

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