Книга: Fedora™ Unleashed, 2008 edition

Errors During Compile

Errors During Compile

Although it is rare that the kernel will not compile, there is always a chance that something has slipped though the regression testing. Let's take a look at an example of a problem that might crop up during the compile.

It is possible that the kernel compile will crash and not complete successfully, especially if you attempt to use experimental patches, add untested features, or build newer and perhaps unstable modules on an older system. For example, the kernel compile will fail on an older-stock Red Hat 7.2 installation using the 2.4.9 kernel when the NTFS file system is selected, either as a loadable module or inline, as shown here:

gcc -D__KERNEL__ -I/usr/src/kernels/linux-2.4.9/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/kernels/linux-2.4.9/include/linux/modversions.h -DNTFS_VERSION="1.1.16" -c -o unistr.o unistr.c
unistr.c: In function 'ntfs_collate_names':
unistr.c:99: warning: implicit declaration of function 'min'
unistr.c:99: parse error before 'unsigned'
unistr.c:99: parse error before ')'
unistr.c:97: warning: 'c1' might be used uninitialized in this function
unistr.c: At top level: unistr.c:118: parse error before 'if'
unistr.c:123: warning: type defaults to 'int' in declaration of 'c1'
unistr.c:123: 'name1' undeclared here (not in a function)
unistr.c:123: warning: data definition has no type or storage class
unistr.c:124: parse error before 'if'
make[2]: *** [unistr.o] Error 1
make[2]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs/ntfs'
make[1]: *** [_modsubdir_ntfs] Error 2
make[1]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs'
make: *** [_mod_fs] Error 2

At this juncture, you have two options:

? Fix the errors and recompile

? Remove the offending module or option and wait for the errors to be fixed by the kernel team

Most users will be unable to fix some errors because of the complexity of the kernel code, although you should not rule out this option. It is possible that someone else discovered the same error during testing of the kernel and developed a patch for the problem: Check the Linux kernel mailing list archive. If the problem is not mentioned there, a search on Google might turn up something.

The second option, removing the code, is the easiest and is what most people do in cases in which the offending code is not required. In the case of the NTFS module failing, it is almost expected because NTFS support is still considered experimental and subject to errors. This is primarily because the code for the file system is reverse-engineered rather than implemented via documented standards. Read-only support has gotten better in recent kernels; write support is still experimental.

Finally, should you want to take on the task of trying to fix the problem yourself, this is a great opportunity to get involved with the Linux kernel and make a contribution that could help many others.

If you are knowledgeable about coding and kernel matters, you might want to look in the MAINTAINERS file in the /usr/src/kernels/linux-2.6/ directory of the kernel source and find the maintainer of the code. The recommended course of action is to contact the maintainer and see if he is aware of the problems you are having. If nothing has been documented for the specific error, submitting the error to the kernel mailing list is an option. The guidelines for doing this are in the README file in the "If Something Goes Wrong" section under the base directory of the kernel source.

Оглавление книги