Mail Archives: cygwin/2010/07/07/15:21:39
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
- Raw text -