[d-kernel] eth && kernel 2.6.26 && old_glibc собранное с headers 2.6.18

gosha =?iso-8859-1?q?gosha_=CE=C1_elins=2Eru?=
Чт Окт 2 09:31:07 MSD 2008

                                                Добрый день.

YK>Вроде как ядра 2.4.х могут собираться максимум gcc 2.96

Переходить на 2.96 очень не хотелось бы: неудобно, т.к. на тек момент один 
кросс-компилятор 4.1.1 используется для кросс сборки ядер 2.6, 2.4 и 
начального загрузчика Redboot.

      М.б. в makefile- ах можно что- то поправить?

      Компиляция ядер 2.4 неизбежна, т.к. кроме прочего мы должны поддерживать 
порт МСВС на своей процессорке. - Все релизы MCBC- , увы,только на ядрах 
2.4 .


diff --git a/Documentation/Changes b/Documentation/Changes
index fce16f7..7331868 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -91,7 +91,12 @@ The Red Hat gcc 2.96 compiler subtree can also be used to 
build this tree.
 You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build
 the kernel correctly.

-gcc 4 is not supported.
+gcc 3.3 and 3.4 are both known to work well. gcc 4.0 and 4.1 also work on
+a several architectures (i386, x86_64, ppc, sparc, sparc64, alpha). Other
+archs will not work. Versions 4.2 and onwards are not supported anymore.
+Supporting them would require massive in-depth changes which will add a
+lot of bugs and might break older compilers. If you don't have any gcc
+below 4.2, check Documentation/using-newer-gcc.txt for instructions.

 In addition, please pay attention to compiler optimization.  Anything
 greater than -O2 may not be wise.  Similarly, if you choose to use gcc-2.95.x
diff --git a/Documentation/using-newer-gcc.txt 
new file mode 100644
index 0000000..7834427
--- /dev/null
+++ b/Documentation/using-newer-gcc.txt
@@ -0,0 +1,187 @@
+Building older versions of GCC compatible with Linux Kernel 2.4
+This document explains how to build an older supported version of the GCC
+compiler from a distribution which only offers incompatible recent versions.
+When Linux 2.4.0 was released in early 2001, GCC 2.95.2 was mainstream and
+GCC 2.91.66 was still widely used. The GCC development model was evolving
+and still confused. Since then, GCC has evolved a lot and stabilized. New
+versions are regularly released, and some old features from the early code
+get deprecated then removed.
+The kernel heavily relies on GCC's capabilities and behaviour. Some of the
+code in Linux looks strange but is in fact intended to workaround early GCC
+bugs. For these reasons, almost every new major GCC release breaks the kernel
+build process. GCC 3.4 was a real pain to introduce as it required a lot of
+rewriting in sensible areas, and GCC 4 required a lot of work, though this
+work was less complicated thanks to the cleanup efforts invested in GCC 3.4.
+Starting with GCC 4.2, the output code randomly fails depending on section
+ordering, which itself depends on the declaration order of functions, module
+parameters and many other things. The nasty part is that the code builds but
+randomly fails at runtime, so it is almost impossible to fix it and ensure
+that everything works, especially in the drivers area where most of the
+problems lie.
+As of 2008, GCC 4.3.2 is advertised as the current release and 4.2 the 
+release. Most distributions have been shipping with 4.2 and 4.3 for some 
+so building Linux 2.4 on a recent distribution has become a real problem for
+users who still have to support kernel 2.4 on servers, firewalls or any other
+Solution : the two-minutes process
+If it is not possible to adapt the kernel to GCC, let's adapt GCC to the
+kernel. We're lucky, building GCC to build just a kernel is not hard and
+is rather fast. I call that a two-minutes process because building an
+older GCC takes about 1 minute, and the kernel with that GCC also takes
+one minute.
+First, you have to select which version of GCC you want to build your kernel
+with. Here are some comments on possible versions :
+  - 2.95.3    : very well tested for the kernel, builds kernels very fast,
+                requires a lot of patches and is rather hard to build..
+  - 3.0       : very buggy, avoid it.
+  - 3.1 & 3.2 : apparently less buggy but rarely used so bugs might have
+                remained unnoticed.
+  - 3.3       : used and tested for a long time. A bit slow but easy to 
+  - 3.4       : was recently introduced, received less testing, though seems
+                OK. Builds kernels faster than 3.3, and is easy to build too.
+  - 4.0 & 4.1 : received little testing, particularly slow but may produce
+                smaller kernels when compiled with -Os.
+Always take the last maintenance version of a compiler (eg: 3.4.6 for 3.4).
+For best reliability and less hassle, I tend to recommend GCC 3.3.6. For
+improved build times (about 30% lower) and improved kernel performance, I'd
+recommend 3.4.6. It tends to produce more efficient code on i386, but has
+had a long history of causing annoyances with inline declarations. It seems
+OK though, and I build all my kernels with it. We'll assume 3.4 is used for
+the rest of this document, though what is described will work with 3.3 to
+4.1 unless stated otherwise.
+1) Download gcc sources from the nearest mirror
+Find a mirror address here : [ http://gcc.gnu.org/mirrors.html ] or download
+from this directory :
+   ftp://ftp.gnu.org/pub/gnu/gcc/gcc-3.4.6/
+Get gcc-core-3.4.6.tar.bz2. It only contains the C compiler, which is what 
+2) Prepare your build environment
+Create a temporary directory where you'll extract the sources. Don't build on
+NFS, it may be slow. Use /tmp if you want. You'll need about 150 MB of free
+space. You'll have to extract the sources in that new directory, and create a
+temporary build directory aside it :
+   $ mkdir /tmp/gcc-build
+   $ cd /tmp/gcc-build
+   $ tar jxf /tmp/gcc-core-3.4.6.tar.bz2
+   $ mkdir build
+3) Configure gcc
+You don't want your new gcc to conflict with the one already in place. I
+recommend simply prefixing it with "kernel-", and not installing it in
+/usr/bin, but rather /opt/kgcc/bin or anywhere else (/usr/local/bin will be
+used by default). I recommend choosing a place you already have in your PATH
+(such as the default /usr/local/bin), so that you don't have to pass the full
+path to the binary when building.
+   $ cd /tmp/gcc-build/build
+   $ ../gcc-3.4.6/configure --disable-locale --disable-shared --disable-nls \
+                            --enable-languages=c \
+                            --prefix=/opt/kgcc --program-prefix=kernel-
+If you're using GCC 3.3, you may see strange messages indicating that some
+programs were not found (eg: kernel-objdump). Simply ignore them.
+Note that you can set a lot of options, even use it as a cross-compiler. 
+very frequent, such a build will not be covered by this document.
+4) Build GCC
+Both GCC 3.3 and 3.4 support parallel building, which reduces build time on 
+systems :
+   $ make -j 4
+If the build fails here because of some options you added above, you'll have 
+remove the build dir and recreate it.
+5) Install your new GCC
+The binaries may be a bit big, but you can strip them. Both GCC 3.3 and 3.4
+support a trick on the command line during the installation process, which
+consists in passing the "-s" flag to "install" :
+   $ sudo make install INSTALL_PROGRAM='${INSTALL} -s'
+It will be installed under the directory referred to by the "prefix" option
+above, or /usr/local/bin if none was specified :
+   $ ls -l /opt/kgcc/bin/kernel-gcc
+   -rwxr-xr-x  3 root root 73124 Sep  6 22:45 /opt/kgcc/bin/kernel-gcc
+   $ /opt/kgcc/bin/kernel-gcc -v
+   Reading specs from /tmp/gcc-3.4.6-build/tmp-inst/opt/kgcc/bin/...
+   Configured with: ../gcc-3.4.6/configure --disable-shared --disable-...
+   Thread model: posix
+   gcc version 3.4.6
+6) Using your new compiler
+The compiler just has to be passed to "make" via the "CC" variable for all
+commands :
+  $ make CC=/opt/kgcc/bin/kernel-gcc -j 4 dep bzImage modules modules_install
+  or more simply, when you have it in your path :
+  $ make CC=kernel-gcc -j 4 dep bzImage modules modules_install
+Building an older GCC on to build an older kernel on a newer machine is not
+really hard. It becomes harder when you have to cross-build (eg: you're
+building on a 64-bit machine for a 32-bit one). But for this, I would 
+that you check the excellent "crosstool" utility from Dan Kegel. It supports 
+wide variety of compilers, contains a lot of fixes and will do all the hard
+patching and configuration work for any combination you want or need.
+Suggestions and comments
+If you find mistakes or want to send comments about this document, please 
+me at <w на 1wt.eu>.

С Уваженим,

Подробная информация о списке рассылки devel-kernel