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 11/24/2010 12:06 AM, Christopher Faylor wrote:
>> 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'm not trying to "get" you.  I'm trying to *understand* you.  That
involves discovering the reasons behind apparent contradictions. "All
things being equal, I'd raise similar concerns about that issue too,
now, but the horse is already out of the barn" is fine.

>> 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's a good one too.  That's why I said "part" of the goal.

Not that I think it will ever be possible to suppress all such magical
thinking...see this thread at mingw-users (if you can stand it):

>>From what I can tell, the "wrapper" would need to:
> Do you have the gcc package now?  

It's at the same site:

You'll also need mingw-w32api, the updated mingw-runtime, and
mingw-pthreads.  Don't install ANY of them unless you first manually
remove the symlinks
or Bad Things(tm) may happen.

The updated gcc-mingw-* gcc-3 addon packages' postinstall scripts are
supposed to handle this for you, but if you try to test the mingw cross
compiler w/o first updating the gcc-3 addons...well, you have to do the
cleanup manually, yourself, first.

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

Well, if it's That Easy(tm) then it sounds like a decent idea.  Although
I've worked with embedded compilers (which are all cross- by nature,
obviously) quite a bit over the last four or five years, I was a tool
user -- not a tool writer.  So, creating an ld wrapper from my end
appears more tricky than it might from your end.

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

We still would need the "real" ld to have been configured with
--with-sysroot[=/usr?].  libtool's cross- support works much better if
the toolchain (gcc and ld) support it, and libtool.m4 checks for it, if
the package using libtool is configured with --with-sysroot[=...]


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