This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygport patch: suppress libtool fixup step
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