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.
Next question?"
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
"pollution").
"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
-T /usr/i686-pc-mingw32/lib/ldscripts/$whatever
--sysroot=/usr/i686-pc-mingw32/sys-root
(unless, of course, the original argv[] included either -T or
--sysroot already)
#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
mode...please no...)
--
Chuck
