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?


Corinna Vinschen wrote:
> Many packages have no requirement for a flag day at all.  What about
> packages like sed, which basically consist of a single application?
> What sense does it make to re-build it with gcc4?

See below.

> Not all maintainers are very active.  That's no criticism, it's just the
> fact of life and, even when not being as active as the core pack, they
> are helping the Cygwin distro a lot.

Yes, they are. And that's the biggest argument against requiring a flag
day.

> Having said that, I think that a flag day is sort of impracticable.
> We can require that new packages and new versions of new packages
> will be built using gcc-4.  But I don't see a reason to rebuild
> already existing package versions.  Time (new upstream release) or
> necessity (spurious crashes) will take care of that.

Well, the problem is this:  There are 55 packages that rely on libintl8
(and 50 that still use libintl3 or libintl2, but that doesn't matter
here). 

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.

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.

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

--
Chuck


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