I am not so sure to what degree this is true. At least a degree of
that in reality seems to be much smaller than some postings in this
group would seem to indicate. A significat portion is likely
classifiable as an "operator error".
A good example is provided by periodical posts "I cannot compile a new
kernel"; usually without any details which would allow to give some
reasonable advice. There is one "gotcha" for novices. One has type
'make boot' instead of 'make zlilo' or 'make zImage' like README says.
I do not think that this explicitely written anywhere, although
undoubtly it should. Personally I found that the first time by
reading Makefiles - which is not an easy method with multilevel
Makefiles as employed by kernel sources. Other than that it is hard
to see what may be a problem; especially if a "victim" uses supplied
scripts for kernel patching instead of doing that "by-hand" when
not sure how.
> - The basic differences between Intel and AXP Linux from a compiler
> point of view.
This is an exciting topic for compiler hackers, but I do not think
that are ANY basic differences here from a user point of view.
> - Differences in size of variables like "integers" in C etc.
> (warnings about casting integers to pointers etc)
This is not a compiler issue per se. C standard says only that short is
no longer than int which is no longer than long. It does not say which,
if any, of these types is good enough to hold a pointer. Unfortunately
there is a log of a buggy code around which makes unwarranted assumptions
"because it happens to work on my system". Anybody who hacked Atari ST,
Amiga (or even ported Unix software to MS-DOS) and later tried Digital
Unix (a.k.a. OSF/1) is well aware about this for years. I am afraid that
if you have buggy code which you want to use, then you have to fix it.
If you are getting warnings about conversions between pointers and
integer types you should assume that without fixing these bugs be deadly.
In any case, the code was broken as given, even if it happened to work
> - Common compiler switches for quick fixes.
"Quick fixes" do not fix anything. The only switch in gcc which helps
is '-Wall', plus possible few others warnings not covered by "all". :-)
You just have to listen to what compiler says. Adding prototypes, if
absent, if often of a great help. Flak from a compiler is good!
A clean compile does not mean that a code is correct, but usually you
are a long way to this goal at that point.
If you are at the dead end then learing how to use -E switch, in order
to look at a code as compiler *really* sees it, can be of some help.
> - Common library problems (overlaping and underlaping)
Eh? You mean misalignment?
At last something which is really a compiler issue. There is some chance
that you may run into a bug in a compiler. Probably bigger with axp
variant of gcc than with Intel as the code is likely younger and used
by a smaller group of people. On the other hand, this compiler was used
to compile quite sizeable working systems, like Linux, so it is not all
that bad. :-) Still that chance is real, both on Intel and AXP.
-- To unsubscribe: send e-mail to firstname.lastname@example.org with 'unsubscribe' as the subject. Do not send it to email@example.com
Copyright © 1995-1997 Red Hat Software. Legal notices