This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Testsuite ad RedHat 7
- To: pfeifer at dbai dot tuwien dot ac dot at
- Subject: Re: Testsuite ad RedHat 7
- From: Joshua N Pritikin <joshua dot pritikin at db dot com>
- Date: Tue, 10 Oct 2000 15:19:32 -0400
- Cc: gcc at gcc dot gnu dot org
- References: <jmd7h8ei3e.fsf@envy.cygnus.com> <Pine.BSF.4.21.0010101950270.583-100000@taygeta.dbai.tuwien.ac.>
On Tue, Oct 10, 2000 at 08:11:57PM +0200, pfeifer@dbai.tuwien.ac.at wrote:
> One of the major problems with Red Hat's decision is the fact that this
> makes for three compilers within one year that break binary compatibility
> in one way or the other: GCC 2.95.2, GCC 2.96 (Red Hat) and GCC 3.0.
Perhaps this is a concern for developers, but do you think end users
care?? Even as a developer, I've come to *assume* that C++ releases are
never binary compatible because I loath investigating monsterously
cryptic linker errors. I always prefer be *sure* about the compiler
version.
This occured to me yesterday: why can't G++ add some magic to each
object file that checks the binary API version? Something like:
struct gcc_compiled_with_check {
static void assert_is_compatible(int version);
gcc_compiled_with_check() { assert_is_compatible(3); }
};
static gcc_compiled_with_check __gcc_compiled_with_check;
I'm not sure about the exact mechanics, but this would nicely eliminate
the ambiguity. I just hate running code that "almost works" only to
realize 4 hours later that I accidentally mismatched compiler versions.
For what it's worth, $0.02, etc.
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)