This is the mail archive of the cygwin-apps 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: ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler


On Tue, Nov 23, 2010 at 10:36:26PM -0500, Charles Wilson wrote:
>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?

I believe I did raise a concern but, even if I didn't and I only thought
about it and never voiced it, it hardly matters that you "got" me.

>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").

My goal was to not make it trivially easy for the standard gcc to sorta
kinda produce mingw binaries, confusing people into thinking that they
could get POSIX functionality with a simple compiler switch.

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

Do you have the gcc package now?  If so, I'll download it and attempt to
create a binutils wrapper to work with it.  I'm really not keen on
having a drawn out discussion about this.  Maybe I'll come to the
conclusion that it's not worth the effort but given that I've done this
kind of thing before, have been working with cross compilers for twelve
years, and have been writing cross compiler wrappers for six years, I'd
need to be see it fail myself.

If I can't make a wrapper then I'll support binutils for mingw.

cgf


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