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

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

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


32bit *non-multilib* mingw64 compiler (because "[multilib] makes no sense for a 32bit compiler", and "there is a place for both [mingw64 32bit and 32bit, as I read your statement in context]")

and a separate

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

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:
In that case, wouldn't the corresponding DLL go into
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).

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


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

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


Problem reports:
Unsubscribe info:

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