Bug 5884 - some programm can't be built with kernel 2.6.10-std26-up-alt1 headers
: some programm can't be built with kernel 2.6.10-std26-up-alt1 headers
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/kernel-headers-std26-up)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-01-16 18:00 by
Modified: 2005-08-31 03:19 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-01-16 18:00:53
I got following error:  
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include    -g -O -DDBUG_ON  
-DSAFE_MUTEX -Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W  
-Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings  
-Wunused  -mcpu=pentiumpro -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG  
-DFORCE_INIT_OF_VARS -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -DSAFE_MUTEX -O1  
-Wuninitialized   -MT bchange.o -MD -MP -MF ".deps/bchange.Tpo" \  
  -c -o bchange.o `test -f 'bchange.c' || echo './'`bchange.c; \  
then mv -f ".deps/bchange.Tpo" ".deps/bchange.Po"; \  
else rm -f ".deps/bchange.Tpo"; exit 1; \  
fi  
In file included from /usr/include/asm/percpu.h:4,  
                 from /usr/include/asm/processor.h:22,  
                 from /usr/include/asm/atomic.h:6,  
                 from ../include/my_global.h:291,  
                 from bfill.c:32:  
/usr/include/asm-generic/percpu.h:8: error: `CONFIG_NR_CPUS' undeclared here  
(not in a function)  
 
Returning to old kernel & headers remove problem 
Steps to Reproduce:
1. get mysql bk tree 5.0 (here is more details  
http://dev.mysql.com/doc/mysql/en/Installing_source_tree.html)  
2. run build script ./BUILD/compile-pentium-debug 
3.
------- Comment #1 From 2005-01-17 09:46:29 -------
reassign
------- Comment #2 From 2005-01-17 15:28:32 -------
In general, including kernel headers from userspace is wrong - headers from the
glibc-kernheaders package should be used for compilation.

#include <asm/atomic.h> should not be used in userspace for several reasons:

1) On some architectures the atomic operations from <asm/atomic.h> are not
available in user mode: e.g., see sparc, sparc64 - atomic_* functions are not
implemented as inlines; on some other architectures the required instructions
are privileged - see
http://mailman.uclinux.org/pipermail/uclinux-dev/2004-January/023757.html .

2) Even on i386 the result of compilation depends on the kernel configuration:
if the kernel was not configured as SMP, the lock prefix before instruction is
omitted, therefore the compiled code will not be SMP-safe, creating subtle bugs.