Skip to contentSkip to conversation

glibc compiling with kernel 2.5.70-bk17

DISCUSSION Riccardo-Maria Bianchi 4 participants 4 messages Jun 19, 2003

lore
Share & tools
lore
#0 lore raw

Good morning,

I'm trying to compiling several version of the glibc but always during the "make" I obtain these errors:

------------------------------------------ cut -----------------------------------------------------------------------------------------------------

In file included from /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:29,

                from ../sysdeps/unix/sysv/linux/sys/sysctl.h:28,
                from ../include/sys/sysctl.h:2,
                from ../sysdeps/unix/sysv/linux/dl-osinfo.h:21,
                from ../sysdeps/unix/sysv/linux/init-first.c:32:
/lib/modules/2.5.70-bk15/build/include/linux/list.h:521:2: warning: #warning "don't include kernel headers in userspace"
In file included from ../sysdeps/unix/sysv/linux/sys/sysctl.h:28,
                from ../include/sys/sysctl.h:2,
                from ../sysdeps/unix/sysv/linux/dl-osinfo.h:21,
                from ../sysdeps/unix/sysv/linux/init-first.c:32:

/lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:39: warning: no semicolon at end of struct or union /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:39: error: parse error before '*' token /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:41: error: parse error before '*' token /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:41: warning: type defaults to int' in declaration of oldval' /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:41: warning: data definition has no type or storage class /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:42: error: parse error before '*' token /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:42: warning: type defaults to int' in declaration of oldlenp' /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:42: warning: data definition has no type or storage class /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:43: error: parse error before '*' token /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:43: warning: type defaults to int' in declaration of newval' /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:43: warning: data definition has no type or storage class /lib/modules/2.5.70-bk15/build/include/linux/sysctl.h:46: error: parse error before '}' token make[2]: *** [/home/nptl/glibc_2_3_1/build/csu/init-first.o] Error 1
make[2]: Leaving directory `/home/nptl/glibc_2_3_1/glibc-2.3.1/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/home/nptl/glibc_2_3_1/glibc-2.3.1'
make: *** [all] Error 2

---------------------------------------------------- cut -------------------------------------------------------------------------------------

I have:
2.5.70-bk17 (even if the 2.5.70-bk15 is shown on the path)
gcc 3.3
binutils 2.13.92

Someone have an idea? :)

Thanks,

Riccardo-Maria Bianchi

#1 lore raw
Quoted 5 lines · Riccardo-Maria Bianchi

Good morning,

I'm trying to compiling several version of the glibc but always during the "make" I obtain these errors:

<snip>

Quoted 3 lines

Someone have an idea? :)

Yes, the kernel headers are currently borked for compiling userspace C libraries. The fix is going to take either a large effort to get a sanitized set of userspace kernel headers created, or someone to be willing to accept patches that fix the problems with the existing headers even though userspace is not supposed to be using them.

#2 lore raw
Quoted 2 lines · Kevin P. Fleming

Yes, the kernel headers are currently borked for compiling userspace C libraries. The fix is going to take either a large effort to get a sanitized set of userspace kernel headers created, or someone to be willing to accept patches that fix the problems with the existing headers even though userspace is not supposed to be using them.

I did get glibc 2.3.2 compiled with gcc 3.3 against the 2.5.70 headers with only 3 changes made to the glibc source.

The result on the other hand wasn't pretty. Most programs did run fine, "ls" was not one of them. It would segfault. (Note to self: If glibc's "make check" fails, don't install it.)

Your first comment is something I had wondered about for a while. A stable set of userspace kernel headers. That would be nice. Of course changes could be made to reflect new kernel interfaces. So they should still be distributed with the kernel source. Then glibc could be compiled against those updates, and the headers installed as the system default. But it wouldn't be so forbidden for userspace to touch them.

Signature · 1 line
Chris
#3 lore raw
Followup to:  <[email protected]>
By author:    Chris Meadors <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 8 lines

Your first comment is something I had wondered about for a while. A stable set of userspace kernel headers. That would be nice. Of course changes could be made to reflect new kernel interfaces. So they should still be distributed with the kernel source. Then glibc could be compiled against those updates, and the headers installed as the system default. But it wouldn't be so forbidden for userspace to touch them.

Yes, this is the "ABI headers" project that has been discussed extensively on this list. It's pretty important, but unlikely to happen in time for 2.6.

-hpa

Signature · 3 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64