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, although supposedly a patch exists for that. But from the packaging perspective multilib is just a nightmare. > 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. > > 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. > 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. 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. > "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. David's libao case was an upstream bug -- the layout was wrong with or without libtool fixups. 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. 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
