This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygport patch: suppress libtool fixup step
On 7/6/2010 6:28 PM, Yaakov (Cygwin/X) wrote:
> On Tue, 2010-07-06 at 14:56 -0400, Charles Wilson wrote:
>> Which of the three interpretations best describes your current effort?
>
> (1) and (2), as both are needed for mingw64. (3) is something
> completely unrelated, nor am I sure how practical it would be (but I'm
> not ruling it out yet, as I haven't thoroughly looked at it).
Thanks for the clarification.
>> Err...yes and no.
>>
>> Ordinarily, yes: that's where the build -- as patched -- puts them. And
>> that's probably what the default cygport ought to do, *in general*.
>> However...
>>
>> To deal with the duplicated DLLs from two different multilib mingw64
>> toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and
>> one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs
>> are actually installed into a completely different directory outside the
>> $triple area.
>
> Why exactly do we need both, and why would one want a x86_64 compiler
> that defaults to i686?
Even for 32bit, mingw64 is a different compiler than mingw.org. mingw64
is sjlj, mingw.org is dw2. The cygwin-hosted mingw.org-based cross
compiler will (probably?) support Ada and Java; AFAICT the mingw64 one
will not, at least not soon (and rumor has it that gcj-compiled progs,
on win32 using sjlj, are painfully slow; dw2 is acceptable).
Finally, the "w32api" and "mingw-runtime" components of mingw64 (*) are
substantially different; mingw64's is more complete, but there may be
some licensing issues that cygwin cares about with respect to using
mingw64's compiler to build OUR '-mno-cygwin' stuff (like mingw-zlib,
mingw-bzip2, etc). This difference of opinion is (one of) the root
causes of the whole mingw.org/mingw64 fork in the first place.
(*) although they do not go by these names in the mingw64 repository
Finally, since cygwin's w32api support is based on the mingw.org w32api
support, for *official* packages that are mingw-ish, we probably want to
use a mingw.org-based compiler.
Now, that answers why we would want an i686-pc-mingw32 32bit
mingw.org-based compiler, and -- for 64bit support -- an
x86_64-w64-mingw32 64bit mingw64-based compiler.
Why also have the 32bit version of the mingw64-based compiler? (e.g. two
separate non-multilib mingw64-based compilers, one for x86_64 and one
for i686, OR a single multilib mingw64-based compiler, supporting both
-m32 and -m64)
1) It's being proposed, now. The long-awaited retire-mno-cygwin
mingw.org-based cross compiler is...still vapor. Been vapor for going
on three years now. Bird in hand, etc.
2) I *believe* the mingw64 guys would LIKE to achieve two goals with
this ITP (and JonY/NightStrike can correct me if I am wrong):
a) get wider use of their compiler, for both 64bit and 32bit
targets, by porting to a popular w32 programming environment.
In doing so, they get a wider user base for *both* the -m64
and -m32 modes, helping to keep both in better working order.
We @ cygwin probably like working compilers, too.
b) ?? ensure the multilib support which they have added to gcc
remains in good working order, by providing the package for
that popular platform configured to exercise that support.
That's good for us, because if cygwin is ever to attempt
a 64bit transition, the starting point for that effort is
probably a cygwin multilib gcc -- and that multilib support
would probably piggy-back on the existing generic-but-tweaked-
for-x86 multilib support they've...implemented? adapted?
extended?
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).
But...
Him who does the work, calls (most of) the shots. And it APPEARS that
JonY wants to do option (B) -- with plans later to provide also option
(C) in parallel.
This may be overkill, but I like it -- my pc is 32bit. Most cygwin
"mingw-ish" packages will be 32bit (mingw-zlib, mingw-bzip2, mingw-lzma,
etc) -- and (*) configuring as "--host=x86_64-w64-mingw32 CFLAGS=-m32"
just seems...wrong somehow. "--host=i686-w64-mingw32" makes so much
more sense, at least to me. So *I* would probably want the "default to
32 bit" one installed on my machine.
(*) notwithstanding the argument above, that "official" mingw-ish
packages should probably be compiled with the mingw.org based (vapor, at
this point) cross compiler.
When you add all of those competing interests together, you end up with
what JonY has proposed.
But...IMO, it's basically up to JonY. He's doing the work; so long as it
doesn't violate packaging standards and the packages operate as
advertised...I don't think we should second-guess too much.
> We are supposed to get a i686-pc-mingw32
> cross-compiler one of these days, isn't that enough for the 32-bit side
> of things?
One of these days...
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.
>> The 64bit dlls are moved manually to $special_prefix/bin64/ and
>> $special_prefix/bin32 -- because these DLLs are "shared" by both
>> toolchains in the specificed -mXX mode, so the "deep" directory inside
>> one toolchain's private area or the other, are both inappropriate.
>
> I'm not sure that I agree, but I'll deal with this when I respond on
> cygwin-apps with a proposed patch for cygport.
OK.
>> But...this is all handled manually, after 'make install'.
>>
>> So...yes, cygport should probably act as you specify, and then
>> mingw64-gcc's cygport script will come along afterwards and further
>> manipulate things.
>
> 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?
>> I still think that the ability to completely *suppress* libtool fixups
>> is needed in general, both until the the cross-compile-supporting
>> version reaches public release, and even afterwards, possibly.
>
> I have yet to see a single legitimate case for not using libtool fixups
> for PE hosts.
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.
"No, your proposed way is wrong" with nothing further is...unhelpful.
--
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