[RFC] ready for cygport to default to gcc4?

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Apr 3 16:39:00 GMT 2009


On Apr  3 11:30, Charles Wilson wrote:
> If I rebuild gettext using gcc4 AND if the switch to gcc4 + shared
> libgcc means that there is some sort of breakage (e.g. between a client
> that uses the old, static runtime, and this DLL that uses the new,
> dynamic runtime) -- then EVERY package that relies on libintl8 just
> broke.

I'm not sure there is really such a interdependency.  Shouldn't the
static libgcc3 functions and the new shared gcc4 libgcc functions
co-exist and not notice each other?

> Unless I bump the ABI number to libintl9.
> 
> But that's exactly what Yaakov was complaining about -- many large
> package suites (like the gnome family, or the kde family) that dlopen
> modules, explicitly hardcode the ABI numbers of the targets.  If we
> force an ABI bump -- to protect existing clients without a rebuild --
> then we force LOTS of patching, in perpetuity, for those large package
> suites.  If we don't do an ABI bump, then we break all client packages
> until they are rebuilt == flag day.

libintl8-1?

> The only clean way out of this mess is "exe's that use static libgcc
> from gcc3 can always and without fail interoperate with DLLs that use
> shared libgcc from gcc4".
> 
> Is that true? ALWAYS and WITHOUT FAIL?  (And don't get me started on
> C++...)

I understand that there is trouble along the way, but, actually, do we
really have a choice?  As you write in your other mail, we're in a
transition period.  We're transitioning in at least two ways, a very
new Cygwin and a very new gcc.  We will have to drag it along and
we can't force other maintainers to do a JIT job.  At the very least,
if some packages break, the maintainer will probably notice (or be
noticed) and provide a new package within a couple of days.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-apps mailing list