This is the mail archive of the cygwin-apps@cygwin.com 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: gcc package idea for consideration.


On Sun, Apr 27, 2003 at 02:56:41AM +1000, Gareth Pearce wrote:
>>>So i'm going to propose an idea, just incase it doesnt get shot down.
>>>Or maybe Chris could convince me that i dont actually need to know
>>>anything to be able to maintain the gcc with cygwin specials package at
>>>all.
>>
>>You need to know C, shell, autoconf, and CVS.  I don't really have to
>>tell you what you need to know.  You could just try it if you are
>>interested.
>
>*chuckle* - I was meaning, above and beyond maintaining a standard gcc
>distribution.  For that I'd need to know things about -mno-cygwin and
>dllexport etc.

If dllexport breaks there are others who will fix it.  I haven't been
involved much with that level of code.  Danny knows much more about this
aspect of gcc than I do.  In fact, Danny seems to know much more about
gcc in general than I.

>>That doesn't help.  There are still many customizations in the
>>gcc/mingw branch that are not in the mainline.  Releasing a package
>>without these customizations would just confuse people.
>
>Ahh, I hate it when I'm right, I suspected this responce.  I would
>suggest a gcc-testing version based on the mingw branch - but, that
>would basically be a gcc package anyway.  (since cygwin-mingw doesnt
>appear to have a 3.3 or 3.4 based branch yet.)
>
>I'll do a more indepth look tommorow, maybe my no-cygwin worries are
>groundless.

The mno-cygwin changes that I made are, er, delicate, gross, and
disgusting.  I told Danny that I'd never been less proud of anything I'd
done.

Getting this working in a reliable invoked a very similar response to
getting things working on Windows.  It was a lot of "Aha! This feature
looks promising.  Hmm.  Why doesn't that work?  Ok.  What about this
approach?  Nope..."  The technique that I eventually settled on was to
use a combination of gcc features that weren't broken + the constructor
attribute to force gcc to do some command line munging prior to anything
reaching main.

The basic problem is that -mno-cygwin is sort of a cross-compiler.  It
needs to be able to switch between two different environments.  To do
that right so that there is no bleed over from the cygwin environment
into the mingw environment is tricky.  I still don't have it right for
the case of libraries.  That seems to require changes to ld.  Or, it
did the last I checked.

I'm happy to answer questions from someone who is interested in
maintaining the package and I'll actively try to help.  I'm not
interested in going into much detail for people who are idly curious
since I would just end up doing it over and over again and suffering the
same type of loop as is evidenced when people start asking "Why are
pipes handled so strangely in cygwin" or "Why is signal code so
complicated".

The good news is that the mno-cygwin code seems to be working fine on
the trunk, or at least it is working as well as it does on the branch.
One of the core maintainers volunteered to help out by introducing
functionality which would help with mno-cygwin but I haven't seem much
evidence of that.  But then, I doubt that he would be letting me know
personally if he made changes.

cgf


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