remove support for gcc < 3.2
Subsystems (2)
PATCH 1/1 remove support for gcc < 3.2
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.
This patch does not yet remove all the #ifdef's and other things that are now no longer required, it only let's the compilation #error for older gcc versions and updates the documentation.
I'd like to see this patch in the next -mm, and if noone will tell a strong reason for keeping support for these gcc versions I'll send the cleanups that are now.
[1] support removed: 2.95, 2.96, 3.0, 3.1
still supported: 3.2, 3.3, 3.4, 4.0
---
Documentation/Changes | 23 ++--------------------- README | 6 +++--- include/linux/compiler.h | 4 +--- 3 files changed, 6 insertions(+), 27 deletions(-)
include/linux/compiler.h renamed from include/linux/compiler.h.old +1 -3
@@ -40,10 +40,8 @@#error no compiler-gcc.h file for this gcc version#elif __GNUC__ ==4 # include <linux/compiler-gcc4.h> -#elif __GNUC__ ==3 +#elif (__GNUC__ ==3 && __GNUC_MINOR__ >=2 )# include <linux/compiler-gcc3.h> -#elif __GNUC__ ==2 -# include <linux/compiler-gcc2.h> #else # error Sorry, your compiler is too old/not recognized.#endif
README renamed from README.old +3 -3
@@ -174,9 +174,9 @@ COMPILING the kernel: - - Make sure you have gcc 2.95.3 available. - gcc 2.91.66 (egcs-1.1.2), and gcc 2.7.2.3 are known to miscompile - some parts of the kernel, and are *no longer supported*. + - Make sure you have gcc >= 3.2 available. + Older versions of gcc are *no longer supported*. + Also remember to upgrade your binutils package (for as/ld/nm and company) if necessary. For more information, refer to Documentation/Changes.
Documentation/Changes renamed from Documentation/Changes.old +2 -21
@@ -48,7 +48,7 @@ hardware, for example, you probably needn't concern yourself with isdn4k-utils. -o Gnu C 2.95.3 # gcc --version +o Gnu C 3.2 # gcc --version o Gnu make 3.79.1 # make --version o binutils 2.12 # ld -v o util-linux 2.10o # fdformat --version
@@ -75,26 +75,7 @@ --- The gcc version requirements may vary depending on the type of CPU in your -computer. The next paragraph applies to users of x86 CPUs, but not -necessarily to users of other CPUs. Users of other CPUs should obtain -information about their gcc version requirements from another source. - -The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it -should be used when you need absolute stability. You may use gcc 3.0.x -instead if you wish, although it may cause problems. Later versions of gcc -have not received much testing for Linux kernel compilation, and there are -almost certainly bugs (mainly, but not exclusively, in the kernel) that -will need to be fixed in order to use these compilers. In any case, using -pgcc instead of plain gcc is just asking for trouble. - -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. - -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 -or derivatives, be sure not to use -fstrict-aliasing (which, depending on -your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing). +computer. Make ----
From: Adrian Bunk <[email protected]>
Date: Mon, 1 Aug 2005 00:26:07 +0200
Quoted 3 lines
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.
And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around.
Hi.
Quoted 3 lines · David S. Miller
Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.
Yes, please don't remove 2.95 support.
Regards,
Nigel
Signature · 4 lines
Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities.
Quoted 7 lines · David S. Miller
From: Adrian Bunk <[email protected]>
Date: Mon, 1 Aug 2005 00:26:07 +0200Quoted 3 lines
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Quoted 7 lines
Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.
And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around.
This is a rather strange form of "progress", especially since in my experience newer gcc's do not show significant reductions in code size...
--
vda
Quoted 9 lines · David S. Miller
From: Adrian Bunk <[email protected]>
Date: Mon, 1 Aug 2005 00:26:07 +0200Quoted 3 lines
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Quoted 7 lines
Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.
And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around.
I don't mean to offend anyone, but it seems that the gcc project, at least WRT x86, has lost its way a bit. The compiler is getting slower, and the generated code is not getting correspondingly faster. Or smaller. I'm not sure about more correct...
Keeping 2.95 might not be a bad idea.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
I'm for its removal. As for the gcc project "losing its way" consider that 3.4 has quite matured and also has much smaller binary size from 3.3. 4.0 however is still too early in its development to come close to surpassing 3.4.
With all the changes and deprications it seems pointless to have to maintain extra code so 3 people can use an obsolete compiler. Something more recent like 3.4 should be used as a bench.
Just my two cents.
From: Joe <[email protected]>
Date: Wed, 10 Aug 2005 20:02:33 -0400
Quoted 2 lines
With all the changes and deprications it seems pointless to have to maintain extra code so 3 people can use an obsolete compiler.
This number is enormously greater than 3, and especially it's important because the folks who are quite important to kernel development (read as: Andrew Morton) rely on the build efficiency of gcc-2.95 so that they can actually get their daily work done.
Some of us spend the majority of our time doing patch applying and verification kernel builds, and often not much more than that.
Therefore kernel build time is enormously important, and gcc-2.95 is the best option as far as that goes.
Quoted 5 lines · Joe
I'm for its removal. As for the gcc project "losing its way" consider that 3.4 has quite matured and also has much smaller binary size from 3.3. 4.0 however is still too early in its development to come close to surpassing 3.4.
I consider that the compiler get bigger and slower with every release. The tools used to find overlong paths in the kernel would work well for gcc. Recent versions are painful, even with a decent SMP machine. The people compiling on laptops could spend a day building with new versions.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write:
Quoted 9 lines
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Quoted 4 lines
My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.
Environments that require kernel compilation, often multiple times, testing, benefit from shorter compile times. It can be the difference between, say, completing a test suite overnight instead of having to wait until tomorrow afternoon. Keeping 2.95, at least, has some value in such environments.
Kurt
Signature · 2 lines
A chubby man with a white beard and a red suit will approach you soon. Avoid him. He's a Commie.
Quoted 15 lines · Kurt Wall
On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write:
Quoted 9 lines
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of timeQuoted 4 lines
My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.
Quoted 5 lines
Environments that require kernel compilation, often multiple times, testing, benefit from shorter compile times. It can be the difference between, say, completing a test suite overnight instead of having to wait until tomorrow afternoon. Keeping 2.95, at least, has some value in such environments.
I *do* still use 2.95 a lot, and I'm not alone, judging from people around me. 2.95 has been the reference for a very long time, that's why it's still so much present. 3.0 and 3.1 (even 3.2) have been there for a very short time frame, but 2.95 and 3.3 really seem to be references compilers.
So please keep support for 2.95.
Cheers,
Willy
Quoted 1 line · Adrian Bunk
This patch removes support for gcc < 3.2 .
Go away.
-miles
Signature · 2 lines
"Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin]
Quoted 5 lines · Adrian Bunk
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
[...]
Quoted 2 lines
[1] support removed: 2.95, 2.96, 3.0, 3.1
still supported: 3.2, 3.3, 3.4, 4.0
This patch in mind, I built the vax-linux kernel again with gcc-HEAD (gcc-4.1) and it blew off in:
$ make V=1 ARCH=vax CROSS_COMPILE=vax-linux- mopboot [...] vax-linux-gcc -Wp,-MD,init/.initramfs.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-171439-vax-linux/install/usr/lib/gcc/vax-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O1 -fomit-frame-pointer -pipe -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=initramfs -DKBUILD_MODNAME=initramfs -c -o init/initramfs.o init/initramfs.c init/initramfs.c:10: error: message causes a section type conflict init/initramfs.c:33: error: head causes a section type conflict init/initramfs.c:80: error: ino causes a section type conflict init/initramfs.c:80: error: major causes a section type conflict [...]
Adding -fno-unit-at-a-time fixed this, but from what Google found, this is actually a bug in the C sources: the __initdata variables are to be put into a read-only segment but are missing a const qualifyer, so -fno-unit-at-a-time seems to hide a bug here.
Could somebody comment on this? Or shall I open a bug report for GCC?
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 2 lines · El Domingo, 31 de Julio de 2005 17:26, escribió:
This patch removes support for gcc < 3.2 .
[1] support removed: 2.95, 2.96, 3.0, 3.1
Please keep the 2.95 support I use to use a lot, on not new hardware. If you have old hardware with not much resources gcc 2.95 works just fine and fast, even you build the main kernel on other machine, by compatibility issues one or two drivers should be builded a lot of times into the older hardware, then we are forced to build gcc 3.4 or something like.
:(
Signature · 3 lines
Gustavo Guillermo Pérez Compunauta uLinux www.compunauta.com
Quoted 5 lines · [email protected] (Gustavo Guillermo Pérez) writes:
Please keep the 2.95 support I use to use a lot, on not new hardware. If you have old hardware with not much resources gcc 2.95 works just fine and fast, even you build the main kernel on other machine, by compatibility issues one or two drivers should be builded a lot of times into the older hardware, then we are forced to build gcc 3.4 or something like.
Moreover I get some weird networking problems which prevent setting up the routes (RNETLINK invalid argument messages) when I compile my kernel with 4.0.1 while the same kernel, same config works fine compiled with 3.2.3...
So eventhough 4.0 is supposed to be supported, it doesn't work too well in my case.
Signature · 1 line
Mathieu Chouquet-Stringer
networking problems when using gcc 4.0.1
Quoted 7 lines · Mathieu Chouquet-Stringer
Moreover I get some weird networking problems which prevent setting up the routes (RNETLINK invalid argument messages) when I compile my kernel with 4.0.1 while the same kernel, same config works fine compiled with 3.2.3...
So eventhough 4.0 is supposed to be supported, it doesn't work too well in my case.
I haven't heard of such a problem.
Please give a complete bug report:
- exact error messages
- kernel version
- self-compiled gcc or distrbution compiler?
Quoted 1 line
Mathieu Chouquet-Stringer
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 10 lines · Adrian Bunk
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Another disadvantage is you'll really piss of the VAX developers (all 3 of us!!!, well me not so much anymore...)
I think there is a gcc 4.x compiler nearly capable of building a kernel for the VAX...
Dave.
Quoted 12 lines · Dave Airlie
Quoted 10 lines · Adrian Bunk
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
Quoted 5 lines
Another disadvantage is you'll really piss of the VAX developers (all 3 of us!!!, well me not so much anymore...)
I think there is a gcc 4.x compiler nearly capable of building a kernel for the VAX...
-sh-3.00# cat cpuinfo
cpu : VAX
cpu type : KA43
cpu sid : 0x0b000006
cpu sidex : 0x04010002
page size : 4096
BogoMIPS : 10.08
-sh-3.00# cat version
Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
Current GCC from CVS (plus minor configury patches) seems to work. We had -fno-unit-at-a-time missing in our arch Makefile which hides a bug in kernel's sources.
I guess that if you remove -fno-unit-at-a-time from i386 and use a current GCC, you'll run into that fun, too.
MfG, JBG
PS: Yes, we lie about page size.
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 7 lines · Jan-Benedict Glaw
...
Current GCC from CVS (plus minor configury patches) seems to work. We had -fno-unit-at-a-time missing in our archMakefilewhich hides a bug in kernel's sources.I guess that if you remove -fno-unit-at-a-time from i386 and use a current GCC, you'll run into that fun, too.
What bug exactly?
I'm sometimes using kernels compiled with gcc 4.0 and without -fno-unit-at-a-time and except for the kernel image being smaller I haven't noticed any difference. Besides this, all architectures except i386 and um are not disabling unit-at-a-time.
There are a few parts of the kernel that might still have stack problems with unit-at-a-time, but I assume that's not what you are talking about?
Quoted 2 lines
MfG, JBG
...
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 10 lines · Adrian Bunk
Quoted 7 lines · Jan-Benedict Glaw
...
Current GCC from CVS (plus minor configury patches) seems to work. We had -fno-unit-at-a-time missing in our archMakefilewhich hides a bug in kernel's sources.I guess that if you remove -fno-unit-at-a-time from i386 and use a current GCC, you'll run into that fun, too.
What bug exactly?
-fno-unit-at-a-time grounded:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ grep fno-unit-at arch/i386/Makefile # CFLAGS += $(call cc-option,-fno-unit-at-a-time)
For presenting it, I built a gcc right from CVS:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ i486-linux-gcc -v Using built-in specs. Target: i486-linux Configured with: /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/src/gcc/configure --disable-multilib --with-newlib --disable-nls --enable-threads=no --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared --target=i486-linux --prefix=/home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr --enable-languages=c Thread model: single gcc version 4.1.0 20050802 (experimental)
...and here you can see it explode even on i386:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ make CC=i486-linux-gcc V=1 bzImage [...] CHK include/asm-i386/asm_offsets.h make -f scripts/Makefile.build obj=init i486-linux-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr/lib/gcc/i486-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/main.o init/main.c init/main.c:415: error: tmp_cmdline causes a section type conflict init/main.c:414: error: done causes a section type conflict init/main.c:536: error: initcall_debug causes a section type conflict include/asm/bugs.h:35: error: __setup_str_no_halt causes a section type conflict include/asm/bugs.h:43: error: __setup_str_mca_pentium causes a section type conflict include/asm/bugs.h:52: error: __setup_str_no_387 causes a section type conflict init/main.c:146: error: __setup_str_nosmp causes a section type conflict init/main.c:154: error: __setup_str_maxcpus causes a section type conflict init/main.c:211: error: __setup_str_debug_kernel causes a section type conflict init/main.c:212: error: __setup_str_quiet_kernel causes a section type conflict init/main.c:220: error: __setup_str_loglevel causes a section type conflict init/main.c:298: error: __setup_str_init_setup causes a section type conflict init/main.c:543: error: __setup_str_initcall_debug_setup causes a section type conflict make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 40 lines · Jan-Benedict Glaw
Quoted 10 lines · Adrian Bunk
Quoted 7 lines · Jan-Benedict Glaw
...
Current GCC from CVS (plus minor configury patches) seems to work. We had -fno-unit-at-a-time missing in our archMakefilewhich hides a bug in kernel's sources.I guess that if you remove -fno-unit-at-a-time from i386 and use a current GCC, you'll run into that fun, too.
What bug exactly?
-fno-unit-at-a-time grounded:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ grep fno-unit-at arch/i386/Makefile # CFLAGS += $(call cc-option,-fno-unit-at-a-time)For presenting it, I built a gcc right from CVS:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ i486-linux-gcc -v Using built-in specs. Target: i486-linux Configured with: /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/src/gcc/configure --disable-multilib --with-newlib --disable-nls --enable-threads=no --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared --target=i486-linux --prefix=/home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr --enable-languages=c Thread model: single gcc version 4.1.0 20050802 (experimental)...and here you can see it explode even on i386:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ make CC=i486-linux-gcc V=1 bzImage [...] CHK include/asm-i386/asm_offsets.h make -f scripts/Makefile.build obj=init i486-linux-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr/lib/gcc/i486-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/main.o init/main.c init/main.c:415: error: tmp_cmdline causes a section type conflict init/main.c:414: error: done causes a section type conflict init/main.c:536: error: initcall_debug causes a section type conflict include/asm/bugs.h:35: error: __setup_str_no_halt causes a section type conflict include/asm/bugs.h:43: error: __setup_str_mca_pentium causes a section type conflict include/asm/bugs.h:52: error: __setup_str_no_387 causes a section type conflict init/main.c:146: error: __setup_str_nosmp causes a section type conflict
Quoted 8 lines
init/main.c:154: error: __setup_str_maxcpus causes a section type conflict init/main.c:211: error: __setup_str_debug_kernel causes a section type conflict init/main.c:212: error: __setup_str_quiet_kernel causes a section type conflict init/main.c:220: error: __setup_str_loglevel causes a section type conflict init/main.c:298: error: __setup_str_init_setup causes a section type conflict init/main.c:543: error: __setup_str_initcall_debug_setup causes a section type conflict make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2
I guess kernel may not yet be ready to be compiled by the latest CVS GCC 4.1.x (currently HEAD). But it should (at least works for me) do the latest CVS GCC 4.0.x.
Martin
Quoted 10 lines · Martin Drab
Quoted 6 lines
init/main.c:212: error:__setup_str_quiet_kernelcauses a section type conflictinit/main.c:220: error:__setup_str_loglevelcauses a section type conflictinit/main.c:298: error:__setup_str_init_setupcauses a section type conflictinit/main.c:543: error:__setup_str_initcall_debug_setupcauses a section type conflict make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2I guess kernel may not yet be ready to be compiled by the latest CVS GCC 4.1.x (currently HEAD). But it should (at least works for me) do the latest CVS GCC 4.0.x.
As I worte previously, I now again do regular compile runs with gcc-HEAD for the VAX port and it works. ...but only, if -fno-unit-at-a-time is supplied.
So I actually suspect two bugs: one in the kernel's sources (missing "const" or rw/ro attributes) and -fno-unit-at-a-time disables some gcc-internal tests that should have fired.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 5 lines · Adrian Bunk
Quoted 2 lines · Jan-Benedict Glaw
I guess that if you remove -fno-unit-at-a-time from i386 and use a current GCC, you'll run into that fun, too.
What bug exactly?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 9 lines · Jan-Benedict Glaw
-sh-3.00# cat cpuinfo
cpu : VAX
cpu type : KA43
cpu sid :0x0b000006
cpu sidex :0x04010002
page size : 4096
BogoMIPS : 10.08
-sh-3.00# cat version
Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
Any change we will see this code in mainline?
Or do you wait for a 25th anniversary of your hardware, or something like that? ;-)
Gr{oetje,eeting}s,
Geert (supporter of Linux
on old systems)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 5 lines · Geert Uytterhoeven
Quoted 5 lines
-sh-3.00# cat cpuinfo
cpu : VAX
cpu type : KA43
cpu sid :0x0b000006
cpu sidex :0x04010002
Quoted 8 lines
Quoted 4 lines
page size : 4096
BogoMIPS : 10.08
-sh-3.00# cat version
Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005Any change we will see this code in mainline?
Or do you wait for a 25th anniversary of your hardware, or something like that? ;-)
I guess the 25th anniversary has already happened -- there was even a
nice history of DEC computing published at that time as it coincided with the 50th anniversary of the company itself. That's for VAX in general, rather than a specific implementation, though.
Anyway I second the question, although I have a bit more interest in this
area these days and I may push the merge myslef if nobody else bothers. ;-)
Maciej
Quoted 12 lines · Geert Uytterhoeven
Quoted 9 lines · Jan-Benedict Glaw
-sh-3.00# cat cpuinfo
cpu : VAX
cpu type : KA43
cpu sid :0x0b000006
cpu sidex :0x04010002
page size : 4096
BogoMIPS : 10.08
-sh-3.00# cat version
Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005Any change we will see this code in mainline?
That's the plan. We haven't publically talked about it yet, but we'd probably like to present the code for review once we
- have enough hardware supported. At least local SCSI drivers for the most common machines should be available, as well as network drivers. That's not yet the case.
- have userspace working again. Currently, a very old gcc is used. I'm working on uClibc (and thereafter GNU libc) in conjunction with gcc-HEAD as time allows.
So yes, we want to show off the code, but we don't want to do that publically and right now. There are still to many places where the code needs some tidy-up (and be it whitespace and comment fixes), but everybody is welcome to peek at our CVS repo
(http://sourceforge.net/cvs/?group_id=2626) or to join the mailing list (at http://www.pergamentum.com/mailman/listinfo/linux-vax).
So if *you* are looking for some beginner's task to start with kernel development, here you go! Oh, and SMP fun will hopefully start soon. A machine is on the way and I hope it'll survive shipping :-)
VAX is also an interesting platform because it's another platform offering TurboChannel slots. So if you're interested in those old Alphas or DECstations, VAX is for you, too.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));