This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> > Then I will proceed in that fashion for *-*-mingw* hosted DLLs, and skip
> > them for other hosts.
> Err...both and mingw64 match that triple:
>    i686-pc-mingw32    : 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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]