Most recent kernel where this bug did not occur: - Distribution: Debian unstable Hardware Environment: SunFire T2000 (1x 8 core T1 niagara) Software Environment: gcc version 4.0.4 20060507 in debian chroot - booted from ubuntu dapper server cd as86 version: 0.16.14 Problem Description: CC arch/sparc64/kernel/setup.o In file included from arch/sparc64/kernel/setup.c:32: include/linux/interrupt.h: In function 'disable_irq_nosync_lockdep': include/linux/interrupt.h:69: warning: implicit declaration of function 'disable_irq_nosync' include/linux/interrupt.h: In function 'disable_irq_lockdep': include/linux/interrupt.h:77: warning: implicit declaration of function 'disable_irq' include/linux/interrupt.h: In function 'enable_irq_lockdep': include/linux/interrupt.h:88: warning: implicit declaration of function 'enable_irq' I inserted #EXTRA_CFLAGS := -Werror to work around this. After commenting out Werror we also have things like: CC kernel/timer.o In file included from include/asm/irq.h:14, from include/linux/kernel_stat.h:4, from kernel/timer.c:22: include/linux/interrupt.h: In function 'disable_irq_nosync_lockdep': include/linux/interrupt.h:69: warning: implicit declaration of function 'disable_irq_nosync' include/linux/interrupt.h: In function 'disable_irq_lockdep': include/linux/interrupt.h:77: warning: implicit declaration of function 'disable_irq' include/linux/interrupt.h: In function 'enable_irq_lockdep': include/linux/interrupt.h:88: warning: implicit declaration of function 'enable_irq' In file included from include/linux/kernel_stat.h:4, from kernel/timer.c:22: include/asm/irq.h: At top level: include/asm/irq.h:112: warning: conflicting types for 'disable_irq' include/linux/interrupt.h:77: warning: previous implicit declaration of 'disable_irq' was here include/asm/irq.h:114: warning: conflicting types for 'enable_irq' include/linux/interrupt.h:88: warning: previous implicit declaration of 'enable_irq' was here this is what we end up with finally: CC mm/fremap.o mm/fremap.c: In function 'install_page': include/asm/pgtable.h:236: error: invalid 'asm': operand number missing after %-letter {standard input}: Assembler messages: {standard input}:445: Error: Illegal operands make[2]: *** [mm/fremap.o] Error 1 make[1]: *** [mm] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17-rc5-mm2' make: *** [debian/stamp-build-kernel] Error 2 Steps to reproduce: make vmlinux || make-kpkg
ok the -Werror part does not strike in vanilla 2.6.17-rc5 (!=mm2) but the assembler foo is still preventing me to build a kernel with the exact same error message. Should i file a seperate bug for that one or would you like to handle it in mm?
That's OK, thanks - we'll get it fixed up.
just FYI I tried 2.6.17-rc5-mm3 for fun with commenting out -Werror, this is what it came up with: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 init/built-in.o: In function `start_kernel': undefined reference to `early_init_irq_lock_type' make: *** [.tmp_vmlinux1] Error 1 for i now have an SMP kernel (2.6.15 ubuntu) running i compiled with make -j 32, that shouldn't hurt anything, right?
Stefan, do you still observe any compile errors in 2.6.18-rc1 or 2.6.18-rc1-mm2? If yes, please attach the .config .
Created attachment 8574 [details] kernel config for working/compiling 2.6.17-mm4 - derived from ubuntu dapper kernel
Sorry i'm a bit busy at the moment. I do not anymore observe any compile errors with 2.6.18-rc1. Furthermore i'm sorry but i totally forgot about this ticket and where able to successfully compile 2.6.17-mm4 end of june which is running on the machine now. I'll attache the kernel config for 2.6.17-mm4 to this message. 2.6.18-rc1-mm2 has some driver glitch - didnt investigate further yet. CC [M] drivers/fc4/fc.o drivers/fc4/fc.c: In function 'fcp_scsi_receive': drivers/fc4/fc.c:432: error: 'Scsi_Cmnd' has no member named 'buffer' drivers/fc4/fc.c: In function 'fcp_scsi_queue_it': drivers/fc4/fc.c:813: error: 'Scsi_Cmnd' has no member named 'buffer' make[2]: *** [drivers/fc4/fc.o] Error 1 make[1]: *** [drivers/fc4] Error 2 make: *** [drivers] Error 2 While we're at it perhaps you can point me to the right direction: I get the following warning when compiling powerdns recursor: g++ syncres.o misc.o unix_utility.o qtype.o logger.o arguments.o lwres.o pdns_recursor.o recursor_cache.o dnsparser.o dnswriter.o dnsrecords.o rcpgenerator.o base64.o zoneparser-tng.o rec_ channel.o rec_channel_rec.o malloc.o selectmplexer.o optional/epollmplexer.o -o pdns_recursor pdns_recursor.o: In function `MTasker<PacketID, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::makeThread(void (*)(void*), void*)': pdns_recursor.cc:(.text._ZN7MTaskerI8PacketIDSsE10makeThreadEPFvPvES2_+0x18): warning: warning: getcontext is not implemented and will always fail pdns_recursor.cc:(.text._ZN7MTaskerI8PacketIDSsE10makeThreadEPFvPvES2_+0x6c): warning: warning: makecontext is not implemented and will always fail pdns_recursor.o: In function `MTasker<PacketID, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::sendEvent(PacketID const&, std::basic_string<char, std::char_traits <char>, std::allocator<char> > const*)': pdns_recursor.cc:(.text._ZN7MTaskerI8PacketIDSsE9sendEventERKS0_PKSs+0x780): war ning: warning: swapcontext is not implemented and will always fail The resulting binary gets executed but then ceases to run without further notice. I'm kind of at a loss here on whether those syscalls are not implemented in the MTasker library, the c++ library or the kernel, perhaps you could enlighten me. 13:36:51.750391 fork(Process 14244 attached ) = 14244 [pid 14243] 13:36:51.750973 setsid() = 14243 [pid 14243] 13:36:51.751227 open("/dev/null", O_RDWR) = 7 [pid 14243] 13:36:51.751526 dup2(7, 0) = 0 [pid 14243] 13:36:51.751763 dup2(7, 1) = 1 [pid 14243] 13:36:51.752020 dup2(7, 2) = 2 [pid 14243] 13:36:51.752281 close(7) = 0 [pid 14243] 13:36:51.752551 rt_sigaction(SIGUSR1, {0x49848, [USR1], SA_RESTART}, {SIG_DFL}, 0xf7c59d78, 4292389812) = 0 [pid 14243] 13:36:51.752892 rt_sigaction(SIGUSR2, {0x5001c, [USR2], SA_RESTART}, {SIG_DFL}, 0xf7c59d78, 4292389812) = 0 [pid 14243] 13:36:51.753193 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 0xf7c59d78, 4292389812) = 0 [pid 14243] 13:36:51.753536 open("/var/run//pdns_recursor.pid", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 7 [pid 14243] 13:36:51.753872 getpid() = 14243 [pid 14243] 13:36:51.754123 write(7, "14243\n", 6) = 6 [pid 14243] 13:36:51.754378 close(7) = 0 [pid 14243] 13:36:51.754607 brk(0x106000) = 0x106000 [pid 14243] 13:36:51.754861 epoll_create(1024) = 7 [pid 14243] 13:36:51.755111 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8 [pid 14243] 13:36:51.755368 epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=8, u64=34359738368}}) = 0 [pid 14243] 13:36:51.755632 epoll_ctl(7, EPOLL_CTL_DEL, 8, {0, {u32=0, u64=0}}) = 0 [pid 14243] 13:36:51.755876 close(8) = 0 [pid 14243] 13:36:51.756124 time([1153222611]) = 1153222611 [pid 14243] 13:36:51.756356 brk(0x108000) = 0x108000 [pid 14243] 13:36:51.756590 time([1153222611]) = 1153222611 [pid 14243] 13:36:51.756812 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 [pid 14243] 13:36:51.757221 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 [pid 14243] 13:36:51.757620 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 [pid 14243] 13:36:51.758029 getpid() = 14243 [pid 14243] 13:36:51.758247 rt_sigreturn(0x3) = 69 [pid 14243] 13:36:51.758486 epoll_ctl(7, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=4, u64=17179869184}}) = 0 [pid 14243] 13:36:51.758732 epoll_ctl(7, EPOLL_CTL_ADD, 5, {EPOLLIN, {u32=5, u64=21474836480}}) = 0 [pid 14243] 13:36:51.758988 epoll_ctl(7, EPOLL_CTL_ADD, 6, {EPOLLIN, {u32=6, u64=25769803776}}) = 0 [pid 14243] 13:36:51.759291 brk(0x11e000) = 0x11e000 [pid 14243] 13:36:51.759542 gettimeofday({1153222611, 759647}, NULL) = 0 [pid 14243] 13:36:51.759780 epoll_wait(7, 100bb8, 1024, 500) = -1 EINTR (Interrupted system call) [pid 14243] 13:36:52.252939 --- SIGCHLD (Child exited) @ 0 (0) --- [pid 14243] 13:36:52.253114 gettimeofday({1153222612, 253204}, NULL) = 0 [pid 14243] 13:36:52.253433 write(2, "swapcontext in schedule: Functio"..., 50) = 50 [pid 14243] 13:36:52.253909 close(6) = 0 [pid 14243] 13:36:52.254278 exit_group(1) = ? Process 14243 detached Process 14244 detached
I'm closing this bug since the bug it covers is fixed. I've sent an email containing a bug report for your drivers/fc4/fc.c problem to the responsible maintainers. I don't know anything about your C++ problem (but that's anyways off-topic here).