List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:November 8 2001 4:22pm
Subject:gcc 2.96
View as plain text  
Hi!

>>>>> "Sasha" == Sasha Pachev <sasha@stripped> writes:

>> 
>> Not useless - "Broken, can be fixed". (it does complain in some cases,
>> while continuing compiling, though - note that this is not a
>> RH-policy, but rather how gcc works)

Sasha> You did not get my point. Let's say you know nothing about C and are trying 
Sasha> to compile somebody's code that compiles with no errors on gcc 2.95. You do 
Sasha> not care to fix up the code as long as the resulting binary works for you -  
Sasha> all you want to do is end up with a working binary on your system. gcc 2.96 
Sasha> in this case is a big pain and what I would do ( even if gcc 2.96 was a 
Sasha> stable release) is simply downgrade to 2.95. My point is that all major 
Sasha> packages that compiled before should still compile if you use the same flags 
Sasha> as before.

Sasha> One needs to remember that in the Unix world, you cannot assume that a 
Sasha> compiler user necessarily knows how to fix the code if you give him an error.

Sasha, In this case I have to agree with Trond's view.
The above is not an argument for us not to use gcc 2.96.

As a software vendor, it's our responsibility to get MySQL to compile
cleanly (without any warnings if possible) with gcc 2.96.

In this sense it's good that gcc 2.96 is more strict as this will
ensure that a lot of code gets better and more portable!

Note however that we here at MySQL AB has NEVER had a problem with gcc
2.96 being more strict.  The only problem we have had with gcc 2.96 is
that in the case of MySQL it's extremely likely that it produces
unreliable code.

Sasha, one can never get all packets to compile with the same flags as
before, so this is a not clever argument.  This is also not really
important;  It's better if the compiler follows strict rules than
allows illegal constructs to slip by.

I propose that we end this argument on this public list here.

Trond, I am open for a private discussion of how to find the bug in
gcc 2.96 that hits us to get this fixed.

The problem is that we currently don't have a system with RedHat 7.2
and gcc 2.96 installed and we don't have a machine available for this
just now.

Is there any change we could get access to one of your machines at
RedHat where we could use gcc 2.96 on MySQL to locate the bug.
The benefit of doing it on your machine would of course be that when
we have a test case, you can easily verify and fix the bug ?

Regards,
Monty
CTO of MySQL AB
Thread
Re: Re: Date and Time Handling Functions in other languagesDaniel BODEA3 Nov
  • Re: Re: Date and Time Handling Functions in other languagesSasha Pachev3 Nov
    • Re: Date and Time Handling Functions in other languages(Trond Eivind Glomsrød)3 Nov
      • Re: Date and Time Handling Functions in other languagesSasha Pachev3 Nov
        • Re: Date and Time Handling Functions in other languages(Trond Eivind Glomsrød)7 Nov
          • Re: Date and Time Handling Functions in other languagesSasha Pachev7 Nov
            • gcc 2.96Michael Widenius8 Nov
              • Re: gcc 2.96Sasha Pachev8 Nov
          • Re: Date and Time Handling Functions in other languagesMichael Widenius8 Nov
Re: Date and Time Handling Functions in other languagesDaniel BODEA4 Nov
Re: Date and Time Handling Functions in other languagesDaniel BODEA7 Nov
  • Re: Date and Time Handling Functions in other languagesTrond Eivind Glomsrød7 Nov