On Fri, 25 Mar 2005, Geert Uytterhoeven wrote:

> On Fri, 25 Mar 2005, F.Laget wrote:
> > Geert Uytterhoeven a �crit :
> > >On Tue, 22 Mar 2005, F.Laget wrote:
> > >>I have some errors at the end of compilation of the m68k linux kernel:
> > >>
> > >>m68k-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ 
> > >>-I/home/donan/mvme/linux/include
> > >>-traditional -c head.S -o head.o
> > >>In file included from head.S:265:
> > >>/home/donan/mvme/linux/include/linux/init.h:134: detected recursion whilst
> > >>expanding macro "__inline__"
> > >>/home/donan/mvme/linux/include/linux/init.h:138: detected recursion whilst
> > >>expanding macro "__inline__"
> > >>head.S:3266: warning: extra tokens at end of #endif directive
> > >>make[1]: *** [head.o] Erreur 1
> > >>make[1]: Leaving directory `/home/donan/mvme/linux/arch/m68k/kernel'
> > >>make: *** [_dir_arch/m68k/kernel] Erreur 2
> > >>
> > >>I build the m68k cross compiler with crosstool 
> > >>http://kegel.com/crosstool/ .
> > >>I use the debian default kernel configuration
> > >>http://debian.savoirfairelinux.net/debian/pool/main/k/kernel-image-2.4.27-m68k/kernel-image-2.4.27-mvme16x_2.4.27-3_m68k.deb
> > >>without SCSI and RAID support.
> > >
> > >Does this patch help?
> 
> > >Anyway, I guess you're using a fairly recent gcc, which may have
> > >problems with other kernel source files, too.
> 
> > Yes i use gcc-3.3.3 and glibc-2.3.2 , i apply this patch but it doesn't
> > worked for me.

I just tried gcc 3.3.4 and 3.3.5 and they don't work either.

"-traditional" seems to be a problem for gcc 3.3. The traditional
preprocessor doesn't permit self-referential macro definitions, and if 
__GNUC__ == 3 && __GNUC_MINOR__ >= 1, then compiler.h puts __inline__ in 
the definition of __inline__.

Yet apparently this kind of macro is OK with the current traditional 
preprocessor, that is, gcc-3.4.3.

Anyway, it turns out that we do have the option to use the standard 
preprocessor, since the only difference in this case is more whitespace.

This patch makes it possible to build the 2.4 m68k CVS with gcc-3.3. I 
tested it by comparing the object files produced before and after the 
patch, and there is no change, neither with Debian gcc-2.95.4 nor FSF 
gcc-3.4.3.

However, there are some subtle differences between the two preprocessors 
(like, unmatched quotes outside of C comments), so maybe the standard C 
preprocessor is not to everyone's taste, given that these files are 
mostly assembler.

-f


--- a/arch/m68k/kernel/Makefile Tue Apr 12 22:36:26 2005
+++ b/arch/m68k/kernel/Makefile Tue Apr 12 22:36:54 2005
@@ -8,7 +8,7 @@
 # Note 2! The CFLAGS definitions are now in the main makefile...
 
 .S.o:
-       $(CC) $(AFLAGS) -traditional -c $< -o $*.o
+       $(CC) $(AFLAGS) -c $< -o $*.o
 
 ifndef CONFIG_SUN3
 all: head.o kernel.o
--- a/arch/m68k/kernel/head.S   Tue Apr 12 22:36:56 2005
+++ b/arch/m68k/kernel/head.S   Tue Apr 12 22:46:38 2005
@@ -3263,7 +3263,7 @@
        moveml  [EMAIL PROTECTED],%d0-%d7/%a2-%a6
        jbra    L(serial_putc_done)
 2:
-#endif CONFIG_MVME16x
+#endif /* CONFIG_MVME16x */
 
 #ifdef CONFIG_BVME6000
        is_not_bvme6000(2f)
--- a/arch/m68k/kernel/entry.S  Tue Apr 12 22:36:56 2005
+++ b/arch/m68k/kernel/entry.S  Tue Apr 12 22:40:42 2005
@@ -77,7 +77,7 @@
 
        | After a fork we jump here directly from resume,
        | so that %d1 contains the previous task
-       | Theoretically only needed on SMP, but let's watch
+       | Theoretically only needed on SMP, but let us watch
        | what happens in schedule_tail() in future...
 ENTRY(ret_from_fork)
        movel   %d1,[EMAIL PROTECTED]
--- a/arch/m68k/kernel/sun3-head.S      Tue Apr 12 22:42:26 2005
+++ b/arch/m68k/kernel/sun3-head.S      Tue Apr 12 22:43:02 2005
@@ -58,7 +58,7 @@
 2:                             
        
 /* Disable caches and jump to high code. */
-       moveq   #ICACHE_ONLY,%d0        | Cache disabled until we're ready to 
enable it
+       moveq   #ICACHE_ONLY,%d0        | Cache disabled until we are ready to 
enable it
        movc    %d0, %cacr      |   is this the right value? (yes --m)
        jmp     1f:l            
 

Reply via email to