On Fri, 2 Feb 2001 16:46:45 +0000 (GMT), Alan Cox <[email protected]> wrote:
>> : It is the original one. I'll try with the -69:
>> :
>> With 2.96-69 the reiserfs seems to work well.
>> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
>
> Excellent. Im just glad to know its a fixed bug.
Yes. But since Red Hat took upon themselves to define "gcc 2.96", they
should have created a new patchlevel (2.96.1) for their fixed compiler.
As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he decides
to outlaw gcc-2.96[.0] for reiserfs compiles.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
> As it stands, there is no way to determine programatically whether
> gcc-2.96 is broken or now. The only way to do it is to check the RPM
> version -- which, needless to say, is a bit difficult to do from the
> C code about to be compiled. So I can't really blame Hans if he decides
> to outlaw gcc-2.96[.0] for reiserfs compiles.
Oh I can see why Hans wants to cut down his bug reporting load. I can also
say from experience it wont work. If you put #error in then everyone will
mail him and complain it doesnt build, if you put #warning in nobody will
read it and if you dont put anything in you get the odd bug report anyway.
Basically you can't win and unfortunately a shrink wrap forcing the user
to read the README file for the kernel violates the GPL ..
Jaded, me ?
Alan
On Fri, Feb 02, 2001 at 09:57:39PM +0000, Alan Cox wrote:
: > As it stands, there is no way to determine programatically whether
: > gcc-2.96 is broken or now. The only way to do it is to check the RPM
: > version -- which, needless to say, is a bit difficult to do from the
: > C code about to be compiled. So I can't really blame Hans if he decides
: > to outlaw gcc-2.96[.0] for reiserfs compiles.
:
: Oh I can see why Hans wants to cut down his bug reporting load. I can also
: say from experience it wont work. If you put #error in then everyone will
: mail him and complain it doesnt build, if you put #warning in nobody will
: read it and if you dont put anything in you get the odd bug report anyway.
:
: Basically you can't win and unfortunately a shrink wrap forcing the user
: to read the README file for the kernel violates the GPL ..
Alan, as a user (one of those few that actually read documentation), I
think it is a good idea to stop people from hurting their data by using
the wrong compiler and assuming everything is ok until shit happens.
As you explained, one either gets the bug reports or the complaints
that $SOURCE doesn't compile. The work for the developers might be
about the same size, the impact on the users' side is less
destructive, though.
Arthur
--
arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de
*pgp key available* dg7sea
A physicist is an atom's way of knowing about atoms.
Alan Cox wrote:
>
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans if he decides
> > to outlaw gcc-2.96[.0] for reiserfs compiles.
>
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
>
> Jaded, me ?
>
> Alan
I fear that you are speaking from experience about the complaints it doesn't
build, and that there is a strong element of truth in what you say.
That said, my opinion is that bug reporting load is not as important as bug
avoidance, but I understand your position has merit to it also.
Hans
On Fri, 2 Feb 2001, Alan Cox wrote:
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
Oh, don't get me wrong, I fully understand that it's a lose-lose
situation. All I'm saying is that it was an incredibly bad idea to have
two compilers, one broken and one ok, identify themselves as the same
version.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Sat, 3 Feb 2001, Hans Reiser wrote:
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
Ion Badulescu <[email protected]> writes:
> On Fri, 2 Feb 2001, Alan Cox wrote:
>
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #warning in nobody will
> > read it and if you dont put anything in you get the odd bug report anyway.
> >
> > Basically you can't win and unfortunately a shrink wrap forcing the user
> > to read the README file for the kernel violates the GPL ..
>
> Oh, don't get me wrong, I fully understand that it's a lose-lose
> situation. All I'm saying is that it was an incredibly bad idea to have
> two compilers, one broken and one ok, identify themselves as the same
> version.
unfortunately, it's not limited to redhat and it's not limited to
redhat's gcc-2.96. gcc-2.95.2 has some bugs (a certain strength
reduction bug comes to mind). no new official gcc has come for over a
year. many distributions have applied a patch to fix the strength
reduction bug. do they all alter their version number? of those that
do, do they alter it consistently?
--
J o h a n K u l l s t a m
[[email protected]]
Don't Fear the Penguin!
--- Makefile.orig Sat Feb 3 00:48:26 2001
+++ Makefile Sat Feb 3 00:45:00 2001
@@ -253,11 +253,23 @@
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
-symlinks:
+symlinks: gccversioncheck
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
+ fi
+
+gccversioncheck:
+ @gccversion=`${HOSTCC} --version`;\
+ echo Using gcc version: $$gccversion;\
+ if [ "x$${gccversion}" != "x2.95.2" ]; then \
+ echo "********************************************************************"; \
+ echo "*** This compiler version is not approved for compiling the kernel"; \
+ echo "*** version: " $$HOSTCC $$gccversion ; \
+ echo "*** Please consider this when reporting bugs" ;\
+ echo "********************************************************************"; \
+ sleep 1; \
fi
oldconfig: symlinks
On 02.03 David Ford wrote:
> How about a simple patch to the top level makefile that checks the gcc
> version then prints a distinct message ..'this compiler hasn't been approved
> for compiling the kernel', sleeping for one second, then continuing on. This
> solution doesn't stop compiling and makes a visible indicator without forcing
> anything.
>
Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
fails with untrusted compilers it is just not selectable.
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
Thus spake J . A . Magallon ([email protected]):
> > How about a simple patch to the top level makefile that checks the gcc
> > version then prints a distinct message ..'this compiler hasn't been approved
> > for compiling the kernel', sleeping for one second, then continuing on. This
> > solution doesn't stop compiling and makes a visible indicator without forcing
> > anything.
> Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
> can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> fails with untrusted compilers it is just not selectable.
What kind of crap is this?
It is not the kernel's job to work around RedHat bugs.
If RedHat ships a broken compiler, it is their responsibility to tell
their customers and provide a working one.
This kind of compatibility crap has caused commercial Unices to
suffocate in their own bloat. We don't need this. And we don't want
this.
Felix
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <[email protected]>
wrote:
>How about a simple patch to the top level makefile that checks the gcc
>version then prints a distinct message ..'this compiler hasn't been approved
>for compiling the kernel', sleeping for one second, then continuing on. This
>solution doesn't stop compiling and makes a visible indicator without forcing
>anything.
A while ago I worked up a nasty bit of make logic which prompted the
user for yes or no... and then did one thing or the other. You could
ask the user if he REALLY wants to continue and wait for a response.
Following is the model code...
John Alvord
=================
_ECHO=@
all: t0 t1 t2 t3 t4 t5 t6
# prompt for input, must be in a separate rule to unbuffer terminal
# output.
t0:
$(_ECHO)echo Enter Y or N: \\c
# capture a line of terminal input, copy to a file, tell user
t1:
$(_ECHO)echo $(shell read ans; echo ans) > ans
$(_ECHO)echo The answer is \\c
$(_ECHO)cat ans
# take first character of answer, upper case, store in another file
# then create two files, one for yes and one for no
# the || exit 0 is to mask the potential grep error, which
# would result in an error message even a - was used to ignore error
# and continue. The result is two files, which may be zero byte
t2:
$(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' >ans1
$(_ECHO)rm -f ansy
$(_ECHO)rm -f ansn
$(_ECHO)grep Y ans1 > ansy || exit 0
$(_ECHO)grep N ans1 > ansn || exit 0
# Check for case where neither answer file is > 0 bytes
t3:
$(_ECHO)test -s ansy || test -s ansn && exit 0; \
echo Answer [$(shell cat ans)] is neither Y or N! && exit 1
# handle Yes case. Exit if Y answer file is 0 bytes or missing
t4:
$(_ECHO)test ! -s ansy && exit 0; \
echo in YES processing
# handle No case
t5:
$(_ECHO)test ! -s ansn && exit 0; \
echo in NO processing
# remove files used during processing
t6:
$(_ECHO)rm -f ans
$(_ECHO)rm -f ans1
$(_ECHO)rm -f ansn
$(_ECHO)rm -f ansy
> > can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> > fails with untrusted compilers it is just not selectable.
>
> What kind of crap is this?
> It is not the kernel's job to work around RedHat bugs.
The kernel actually works round gcc 2.7.2, egcs-1.1.2 and gcc-2.95 bugs, but
in this case having some CONFIG option and all the glue for it isnt right
especially because there _is_ a fixed compiler and the documentation tells
you to use 1.1.2 or 2.95 anyway
I hate to say it but I think Hans might have the right answer here. As an administrator that has worked in large multi hundred million dollar companies where 1 hour of downtime == $75,000 in lost income proactive prevention IS the right answer. If the gcc people need to compile with the .96 rh version then they can apply a removal patch hans provides in the crash message. This makes it easy to remove the safeguard and blow yourself up at will after being suitibly called a dumbass.
I do understand your desire to keep things simple and not put a safetynet out for every single moron out there. Personaly I despise them. But I also understand the evil necessity of doign this for somet hings that are this serious of a risk.
From the debate raging here is what I gathered is acceptable....
make it blow up fataly and immediatly if it detects Red Hat + gcc 2.96-red_hat_broken(forgot version num)
make it provide a URL to get the patch to remove this safeguard if you really want this.
The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch.
Brian Wolfe
On Sat, Feb 03, 2001 at 01:06:52AM +0300, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > As it stands, there is no way to determine programatically whether
> > > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > > version -- which, needless to say, is a bit difficult to do from the
> > > C code about to be compiled. So I can't really blame Hans if he decides
> > > to outlaw gcc-2.96[.0] for reiserfs compiles.
> >
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #warning in nobody will
> > read it and if you dont put anything in you get the odd bug report anyway.
> >
> > Basically you can't win and unfortunately a shrink wrap forcing the user
> > to read the README file for the kernel violates the GPL ..
> >
> > Jaded, me ?
> >
> > Alan
>
> I fear that you are speaking from experience about the complaints it doesn't
> build, and that there is a strong element of truth in what you say.
>
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
>
> Hans
Brian Wolfe writes:
> I hate to say it but I think Hans might have the right answer here.
> As an administrator that has worked in large multi hundred million
> dollar companies where 1 hour of downtime == $75,000 in lost income
...
> From the debate raging here is what I gathered is acceptable....
>
> make it blow up fataly and immediatly if it detects Red Hat +
> gcc 2.96-red_hat_broken(forgot version num) make it provide a URL
> to get the patch to remove this safeguard if you really want this.
>
> The fatal crash should be VERY carefull to only trigger on a redhat
> system with the broken compiler. And to satisfy your agument that
> people may need to be able to use it, provide a reverse patch to
> remove this safeguard in one easy cat file | patch.
There is another way: directly test for the bug.
In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
> From the debate raging here is what I gathered is acceptable....
>
> make it blow up fataly and immediatly if it detects Red Hat + gcc 2.96-red_hat_broken(forgot version num)
> make it provide a URL to get the patch to remove this safeguard if you really want this.
>
> The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch.
No. There are *many* other compilers out there which are much *more* broken
then anything RedHat has recently shipped. Unfortunatly, there is no easy
way to accuratly test for such bugs (because once they can be boiled down to
a simple test they are very rapidly fixed, what's left is voodoo).
> administrator that has worked in large multi hundred million dollar compani=
> es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> ion IS the right answer. If the gcc people need to compile with the .96 rh =
> version then they can apply a removal patch hans provides in the crash mess=
> age. This makes it easy to remove the safeguard and blow yourself up at wil=
> l after being suitibly called a dumbass.
With all due respect, if you are running $75,000/hr of lost income (which btw
is small fry to a lot of folks) shouldn't you have an engineering team who
a) read the documentation.
b) run tests before rolling out software
Alan
> In an __init function, have some code that will trigger the bug.
> This can be used to disable Reiserfs if the compiler was bad.
> Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll see about dropping the test into -ac that
way.
> No. There are *many* other compilers out there which are much *more* broken
> then anything RedHat has recently shipped. Unfortunatly, there is no easy
> way to accuratly test for such bugs (because once they can be boiled down to
> a simple test they are very rapidly fixed, what's left is voodoo).
The problem isn't so much that compilers get bugs and they get fixed as
soon as a good test case pops up, its that end users don't habitually check
for a compiler update. Being able to say 'look go get a new compiler' is
productive. Especially as the kernel can panic with a URL ;)
Alan
Alan Cox wrote:
>
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a removal patch hans provides in the crash mess=
> > age. This makes it easy to remove the safeguard and blow yourself up at wil=
> > l after being suitibly called a dumbass.
>
> With all due respect, if you are running $75,000/hr of lost income (which btw
> is small fry to a lot of folks) shouldn't you have an engineering team who
> a) read the documentation.
> b) run tests before rolling out software
>
> Alan
Think of it as being like gun safety. You don't seek to develop habits that
protect you when you are awake and alert and paying attention, you strongly seek
to develop the sort of habits that will protect you if for one moment your
attention wanders and you do something completely stupid. Oh dear, there may be
some cultural translation difficulty with this example.:-)
User protection is a variant on that. To have an attitude that if the user was
only alert and intelligent at the moment and as educated as you are in how to
compile a kernel, this is just, ahem, not right.
All things must be kept in balance though, and not taken to extremes. But when
the number of users complaining exceeds some amount relative to the cost to
protect them, they should be protected from their lack of education in what
distro to not trust the compiler on.
You can go ahead and write software for the always alert and always intelligent
and never too hasty and always read the README users, and I'll be happy with
having the rest of the market for ReiserFS.:-)
Hans
Alan Cox wrote:
>
> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
>
> Thats actually quite doable. I'll see about dropping the test into -ac that
> way.
NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.
Hans
Alan Cox wrote:
>
> > No. There are *many* other compilers out there which are much *more* broken
> > then anything RedHat has recently shipped. Unfortunatly, there is no easy
> > way to accuratly test for such bugs (because once they can be boiled down to
> > a simple test they are very rapidly fixed, what's left is voodoo).
>
> The problem isn't so much that compilers get bugs and they get fixed as
> soon as a good test case pops up, its that end users don't habitually check
> for a compiler update. Being able to say 'look go get a new compiler' is
> productive. Especially as the kernel can panic with a URL ;)
>
> Alan
Here we agree.
Hans
On Mon, 5 Feb 2001, Alan Cox wrote:
> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
>
> Thats actually quite doable. I'll see about dropping the test into -ac that
> way.
It would actually be nice to have a whole collect of compiler tests in the
kernel; whenever we fall over a compiler bug add the test and leave it in.
Possibly as a separate block of the code.
One thing to remember is not to test for compiler versions; versions which
cause problems on x86 might work fine on real systems and the otherway
round.
Dave
--
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:[email protected] +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: [email protected] http://www.treblig.org |
\------------------------------------------------------------------/
> > Thats actually quite doable. I'll see about dropping the test into -ac that
> > way.
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.
I was thinking boot time.
Alan Cox wrote:
>
> > > Thats actually quite doable. I'll see about dropping the test into -ac that
> > > way.
> > NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.
>
> I was thinking boot time.
and if reiserfs is the root partition? You really want to make them reboot to
the old kernel and recompile rather than making them just recompile?
Stop trying to blame something other than the compiler, it is ridiculous.
Hans
> > I was thinking boot time.
> and if reiserfs is the root partition? You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?
I want to make sure they get a sane clear message telling them where to
find the correct compiler and that they didnt read the docs
> Stop trying to blame something other than the compiler, it is ridiculous.
WTF does it have to dow with blaming something other than the compiler ?
Its going to print something like
Linux 2.4.2-ac3 blah blah
Error: This kernel was built with a buggy gcc. Please go to
http://.... and upgrade
On Mon, 5 Feb 2001, Hans Reiser wrote:
> and if reiserfs is the root partition? You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?
>
> Stop trying to blame something other than the compiler, it is ridiculous.
Blaming the compiler is one thing - however stopping the user running into
a bug caused by a dodgy compiler is a different one.
Putting a test in to identify a duff compiler and then stop the kernel
doing something potentially dangerous given that it has been compiled in a
broken way is perfectly reasonable.
Dave
--
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:[email protected] +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: [email protected] http://www.treblig.org |
\------------------------------------------------------------------/
Alan Cox wrote:
>
> > > I was thinking boot time.
> > and if reiserfs is the root partition? You really want to make them reboot to
> > the old kernel and recompile rather than making them just recompile?
>
> I want to make sure they get a sane clear message telling them where to
> find the correct compiler and that they didnt read the docs
>
> > Stop trying to blame something other than the compiler, it is ridiculous.
>
> WTF does it have to dow with blaming something other than the compiler ?
>
> Its going to print something like
>
> Linux 2.4.2-ac3 blah blah
> Error: This kernel was built with a buggy gcc. Please go to
> http://.... and upgrade
Sorry, thought you were going to make it only reiserfs disabling, ok, if we do
both this and make the compile fail, that is pretty thorough, effective, useful,
etc.
Hans
On Mon, 5 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > In an __init function, have some code that will trigger the bug.
> > > This can be used to disable Reiserfs if the compiler was bad.
> > > Then the admin gets a printk() and the Reiserfs mount fails.
> >
> > Thats actually quite doable. I'll see about dropping the test into -ac that
> > way.
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.
A simple "make test" to run this sort of automated sanity check would be
good, I think?
James.
Oh believe ,e I agree. But here we run into the dilbert principal and we really should be sarter than the IT Diredtor that makes stupid decisions and overrides thier admins with insane schedules that prevent a full reading of the docs. 8-( Believe me, it's far more common a situation than you would ever expect.
Brian
On Mon, Feb 05, 2001 at 11:55:16AM +0000, Alan Cox wrote:
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a removal patch hans provides in the crash mess=
> > age. This makes it easy to remove the safeguard and blow yourself up at wil=
> > l after being suitibly called a dumbass.
>
> With all due respect, if you are running $75,000/hr of lost income (which btw
> is small fry to a lot of folks) shouldn't you have an engineering team who
> a) read the documentation.
> b) run tests before rolling out software
>
> Alan
Hans Reiser writes:
> Alan Cox wrote:
>> [Ablert Cahalan]
>>> In an __init function, have some code that will trigger the bug.
>>> This can be used to disable Reiserfs if the compiler was bad.
>>> Then the admin gets a printk() and the Reiserfs mount fails.
>>
>> Thats actually quite doable. I'll see about dropping the test
>> into -ac that way.
>
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail
> at compile time.
Detection at compile time is not reliable. Just last week, on a
plain x86 box with a good gcc, I was compiling with a compiler
called "/usr/local/bin/powerpc-linux-gcc". Guess what that does.
My compiler was not in the RPM database. My compiler could not
produce executables that would run on the build system, so build-time
tests wouldn't work. Compiler version information is fairly useless,
since x86-specific bugs don't matter at all. Maybe I even patched
my compiler.
Complaints about the local compiler are useful, but not sufficient.
They only protect the menuconfig program, the mkdep program...
As above, actual bug tests are better than trying to interpret
what the compiler reports for a version.
"Albert D. Cahalan" wrote:
>
> Hans Reiser writes:
> > Alan Cox wrote:
> >> [Ablert Cahalan]
>
> >>> In an __init function, have some code that will trigger the bug.
> >>> This can be used to disable Reiserfs if the compiler was bad.
> >>> Then the admin gets a printk() and the Reiserfs mount fails.
> >>
> >> Thats actually quite doable. I'll see about dropping the test
> >> into -ac that way.
> >
> > NOOOOO!!!!!! It should NOT fail at mount time, it should fail
> > at compile time.
>
> Detection at compile time is not reliable. Just last week, on a
> plain x86 box with a good gcc, I was compiling with a compiler
> called "/usr/local/bin/powerpc-linux-gcc". Guess what that does.
>
> My compiler was not in the RPM database. My compiler could not
> produce executables that would run on the build system, so build-time
> tests wouldn't work. Compiler version information is fairly useless,
> since x86-specific bugs don't matter at all. Maybe I even patched
> my compiler.
>
> Complaints about the local compiler are useful, but not sufficient.
> They only protect the menuconfig program, the mkdep program...
> As above, actual bug tests are better than trying to interpret
> what the compiler reports for a version.
We only detect bad compilers, and our particular bad compiler only exists on one
particular distro, so it works.
Hans