Re: GCC 3.0 Release Criteria

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   >>>>> "Chip" == Chip Salzenberg <chip@valinux.com> writes:

   Chip> According to Joerg Faschingbauer:
   >> The reason why I am asking is that the --enable-shared of current
   >> releases (making libstdc++ a shared library) is mostly useless for
   >> serious development. Releasing my programs, I cannot expect libstdc++
   >> - generated with the same compiler version that I use to build with -
   >> be present at the customer's site.

   Chip> Straw man, I think.  If by "serious" you mean "targeting unknown
   Chip> systems", then you probably want to link with static libc also, yes?

   Don't tell me this!

   - First, usually every system - even unknown - has a libc installed
     somewhere around (which tries to be bincompatible as far as possible
     - but read on). This is not generally the case with libstdc++, is
     it? Solution: libstdc++.a.

Indeed!  Since the C++ ABI isn't really stable yet every major GCC
release has a different libstdc++.so, and it is unlikely that every
user has all of these installed.  Most distributions install a few of
the most popular ones though.

   - Second, from what I heard - correct me if I'm wrong - you must build
     libstdc++ with the same compiler you use to build your program
     with. So, when I build my program with gcc 2.95.2 and deliver it to
     an "unknown" system which happens to have a egcs-1.0.3-built
     libstdc++.so, there's no guarantee that it works. Solution:
     libstdc++.a.

Those libstdc++.so's should have different sonames, and if the right
one isn't present the program won't run.  Of course some distributions
have provided slightly incompatible ones with the same name, because
they applied a fix that affected binary compatibility.  Of course some
people have installed libstdc++.so's from pre-releases that are not
binary compatible with anything.

   - Third (no joke), because of an incompatibility (I assume in libio)
     introduced somewhere between glibc 2.0.6 and 2.1.<dunno>, the
     programs linked statically against the libstdc++.a (which was built
     against glibc 2.0.6) failed running on a 2.1.<dunno> system. Of
     course, employing libstdc++.so would have solved this, but
     unfortunately there's the second point above. Solution: link libc
     static. (Mad laughter here!)

This should not be true.  If you develop an app on a glibc 2.0.6
system and link it statically against a libstdc++.a built against
glibc 2.0.6, that app should work fine on a glibc 2.1 system.
Unfortunately, early releases of glibc 2.1 contained quite a few bugs
which prevented this from working.  Those bugs were hard to fix, the
quality of bug-reports was generally very poor (sometimes even
insulting) and usually involved large binary-only apps.  So it took
quite a lot of time to fix.  I believe there are no know bugs related
to this issue in glibc 2.1.3.

What you *cannot* do is link an app against glibc 2.1 and a
libstdc++.a built against 2.0.6.  In that case you'd have to rebuild
your libstdc++.a.

   That's how we deliver current releases. I'm confident that, for future
   releases, we can require customers to have a glibc 2.1 system,
   assuming things to settle and stabilize. We would then take the
   dynamic libc, but still the static libstdc++ unless convinced
   otherwise.

Well, the hope is that the C++ ABI will stabilize :-).

Mark