This is the mail archive of the
mailing list for the Cygwin project.
Re: ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler
On 11/23/2010 7:41 PM, Christopher Faylor wrote:
> On Tue, Nov 23, 2010 at 05:28:46PM -0500, Charles Wilson wrote:
>> DO NOT ALLOW setup.exe to install mingw-binutils yet, even though
>> setup.exe will whine about it. Nor mingw-w32api or mingw-runtime, or
>> any of the mingw libraries (zlib, bzip2, xz, libgpg-error, libgcrypt)
> I'm not comfortable with the existence of two binutils packages in the
> distribution which do the same thing. I'm not keen to play the
> coordination game with anyone, e.g., "Why is there a mingw-binutils-2.21
> and a binutils 2.20?"
"One is for building cygwin apps. The other is for building non-cygwin
apps. They are maintained by different people, with different schedules
and tolerances for those 'updates' that often cause destabilization.
Why do you not have similar concerns with the mingw64-i686 and
mingw64-x86_64 toolchains? (Okay, granted, the mingw64-x86_64-binutils
is PEP; but the only real difference between cygwin binutils and
mingw64-i686-binutils is, again, the search path).
I thought part of the goal of using an actual mingw cross compiler as
opposed to the -mno-cygwin garbage, was to *decouple* the development
and maintainance (in addition to fixing the /usr/lib and /usr/include
"If you want to build win32 non-cygwin stuff, install the mingw cross
compiler toolchain. Like all cross compiler toolchains, it incorporates
a separate compiler suite and linker tools."
That having been said...
> Please investigate a wrapper for ld rather than a whole new package.
> IMO, it is a bad idea to include a different version of the same package
> just to essentially stop ld from searching /usr/lib by default.
Well, for it to work at all, you need to release a "native" binutils
with sysroot support enabled, even if that sysroot is simply /usr.
Otherwise, the wrapper won't be able to reset the sysroot to the mingw
location when it execs "the real" ld.
>From what I can tell, the "wrapper" would need to:
1) parse all the -n -r -R (and other(?)) options to determine which
linker script the native ld would use.
2) Then, create a new argv list with several additional arguments
(unless, of course, the original argv included either -T or
#2 isn't all that complicated, but #1...I'm not sure about how to do
that one. It also means the wrapper needs to know more about the
innards of ld than I think is wise.
I guess my question is, why do we CARE if the mingw toolchain is a
different version than the cygwin one? This gcc is 4.5.1 while our
current cygwin compiler is still 4.3.4...is that a problem? (4.3.4
requires a LOT of extra patches and effort to get working in mingw