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: [RFC] ready for cygport to default to gcc4?


Charles Wilson wrote:
> Yaakov (Cygwin/X) wrote:
>> Are maintainers ready for cygport-0.9 (for 1.7 only) to default to gcc4?
> 
> No.
> 
> gcc4 is still an *experimental* release:
> 
> "[ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2"
> http://cygwin.com/ml/cygwin/2009-03/msg00378.html
> 
> We shouldn't default to using it until the gcc maintainer is confident
> enough in it to promote it officially. I know it's a bit of a
> chicken/egg problem, but there you go.
> 
> (Besides, IIRC there is still an existing problem with g++, and
> overriding operator new/delete. This would be a problem for xerces.)

  Mm.

  On the one hand, I think GCC4 is in very good and reliable shape.  On the
other there's this C++ issue, which is still anything up to a couple of weeks'
work and a binutils update away from properly resolving.

  I considered suggesting GCC-4 with everything statically linked, but that
would give us exceptions-out-of-dlls problems owing to the sjlj/dw2 switch,
and you can't have static libstdc++ (which would resolve the overriding
problem) with shared libgcc.

  I wonder exactly how many packages there are in the distro that would
actually suffer from this problem.  It would be an option to switch the
default and tell maintainers they'll have to test their packages and
special-case the ones that need the overriding behaviour to work right, or
perhaps continue with gcc-3 (sjlj and all static linking) for now, but I don't
have a good feel for just how much or little grief that might cause.


  Hmm, I feel a third option coming on.

  I could do a special case hack, that works just for libstdc++, by putting
the objects for the overrideable functions into the import library archive
instead of the DLL.  But then we'd still have problems if a library built as a
DLL overrides operator new (that bit will work), and then the application does
so too; we'll just have moved the interposing problem 'out one layer' from
libstdc++ to the client dll.  Not sure if I like that either.

  I think I'd better just pull a bunch of all nighters and get this weak
symbol support working ASAP :-)

    cheers,
      DaveK


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