Re: kernel headers question.
On 8/19/06, Steven W. Orr <[EMAIL PROTECTED]> wrote: It seems to me that we stopped using kernel headers a *long* time ago, but I could be wrong. One of the consistent losses in Linux is the refusal of the kernel people to provide a standard userland interface. They say we shouldn't use the kernel's own headers, but don't provide an alternative. So, in a sense, there's no "right" way to do this. Some people have provided "sanitized" kernel headers. Distributions generally do the same. I'm not sure what that gets us. Up to and through the 2.4 series, there was a vague promise that the kernel-to-user runtime interface wouldn't change in backward-incompatible ways within x.y revisions (e.g., a user program built against kernel 2.4.7 would run against kernel 2.4.11). I believe that went out the window with 2.6. I think we're just supposed to pray things work. :-( I recently had the dismal experience of trying to build the LTSP Build Environment on CentOS 4.3. It kept puking due to kernel header issues. I couldn't get it work, and the little feedback I got from the community was that it's a crap shoot for everybody. It's enough to make one want to try BSD I'm hoping this is doable because I'm hard pressed to understand what things I would need to worry about in userspace that would be kernel specific. Anything that makes a system call is potentially effected by kernel changes. As a contrived example, if the system call number for write(2) is 4 in the current release, but then changes to 5 in the next kernel release, and I don't update my userland, things are going to get interesting. A less contrived example would be when the kernel changed the iptables interface, so you had to update the iptables tools to get them to do anything more than segfault. In theory, the user-to-kernel interface is kept well isolated within glibc, so if the kernel changes, one only needs to update glibc. See above about iptables. And this doesn't help you any, since you are actually building the C library. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: kernel headers question.
Steven W. Orr writes: > =>The only really linux specific part in gcc/binutils is the crt*.o > =>. Even libgcc.a, libiberty.a, libstdc++.a aren't very kernel > =>specific, but do require something in the lines of header files to > =>build. > => > =>I generally use something along the lines of: > => > =>construct sys include from a 'close-enough kernel' > > This is probably really the heart of the question. Is any early 2.4 set of > headers going to be good enough for any *libc to be run on any 2.4 series > that is equal to or later than the set of headers used? Do I need to have > a different set for 2.6 kernels or can I continue use of the headers that > came from a 2.4 kernel? x86 should be rather good between 2.4 and 2.6, but other architectures may be more different and have conflicts however I don't recall any issues. You may run into problems building the latest and greatest glibc against 2.4 headers as it may be looking for new syscalls such as sched_getaffinity() which were added in 2.6. > =>build binutils cross > =>build gcc cross stage 1 (only c support) > =>build glibc cross > =>build gcc cross stage 2 (c & c++) > =>blow away this glibc results > =>install stage 2 gcc, binutils, and sys includes system wide. > => > =>(if you want c++ support you unfortunately need to build a cross > =>libc inbetween stage 1 and 2.) > > I don't understand why? In order to build shared versions of libraries ld needs crt1.o as well as -lc (both built as part of *libc) to link a .so. So more correctly I should have said --enable-shared (highly desirable in stage 2) requires glibc although I recall c++ may also need it. I just ran a build skipping glibc and the first failure in stage 2 was building libgcc_s.so.1 because it couldnt' find crt1 and libc. > =>The specific kernel headers are more important when building your > =>*libc as any change in the syscall area has a big effect on libc. > > Agreed, but I'm not sure I understand why syscall comes into play. I get > that there are constants to syscall that correspond to new system calls in > newer kernels, but I'm not sure I understand why i care. see above. -- Dave ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: kernel headers question.
On Sunday, Aug 20th 2006 at 13:50 -0400, quoth Dave Johnson: =>Steven W. Orr writes: =>> So having said all that, is it safe to say that for all versions of =>> 2.4 and 2.6 series kernels, it's ok to have one old version of =>> glibc-kernheaders? Or is there some reason that I am constrained to =>> having seperate kernel headers for each project thereby necessitating =>> that each version of gcc, binutils, and UClibc is dependant on the =>> version of linux that it will run against? => => =>When building gcc/binutils you generally do not need the specific =>version of the kernel headers (or more specifically =>--with-headers= from gcc's configure line). So far so good. =>The only really linux specific part in gcc/binutils is the crt*.o =>. Even libgcc.a, libiberty.a, libstdc++.a aren't very kernel =>specific, but do require something in the lines of header files to =>build. => =>I generally use something along the lines of: => =>construct sys include from a 'close-enough kernel' This is probably really the heart of the question. Is any early 2.4 set of headers going to be good enough for any *libc to be run on any 2.4 series that is equal to or later than the set of headers used? Do I need to have a different set for 2.6 kernels or can I continue use of the headers that came from a 2.4 kernel? =>build binutils cross =>build gcc cross stage 1 (only c support) =>build glibc cross =>build gcc cross stage 2 (c & c++) =>blow away this glibc results =>install stage 2 gcc, binutils, and sys includes system wide. => =>(if you want c++ support you unfortunately need to build a cross =>libc inbetween stage 1 and 2.) I don't understand why? => =>The specific kernel headers are more important when building your =>*libc as any change in the syscall area has a big effect on libc. Agreed, but I'm not sure I understand why syscall comes into play. I get that there are constants to syscall that correspond to new system calls in newer kernels, but I'm not sure I understand why i care. =>Note that this part has settled down a long time ago and you can =>usually get away with a close-enough kernel here too. If you're not =>changing syscalls or other kernel headers then you can build your =>*libc once and forget it. => =>workareas consist of: => =>build kernel =>build *libc (rebuilding isn't needed that often) =>build everything else => =>If you're not changing your libc or major changes in your kernel (that =>would effect *libc) you can build the libc and install it system wide =>along with gcc/bintuils. I see a glimmer of hope. => =>Also note, you need to make sure binutils and gcc dont look in =>/usr/include or /usr/lib by default, but instead uses your sys includes =>you build with and the libgcc.a, libiberty.a and libstdc++.a that you =>built. Definitely agreed. => => =>-- =>Dave Thanks. :-) -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: kernel headers question.
Steven W. Orr writes: > So having said all that, is it safe to say that for all versions of > 2.4 and 2.6 series kernels, it's ok to have one old version of > glibc-kernheaders? Or is there some reason that I am constrained to > having seperate kernel headers for each project thereby necessitating > that each version of gcc, binutils, and UClibc is dependant on the > version of linux that it will run against? When building gcc/binutils you generally do not need the specific version of the kernel headers (or more specifically --with-headers= from gcc's configure line). The only really linux specific part in gcc/binutils is the crt*.o . Even libgcc.a, libiberty.a, libstdc++.a aren't very kernel specific, but do require something in the lines of header files to build. I generally use something along the lines of: construct sys include from a 'close-enough kernel' build binutils cross build gcc cross stage 1 (only c support) build glibc cross build gcc cross stage 2 (c & c++) blow away this glibc results install stage 2 gcc, binutils, and sys includes system wide. (if you want c++ support you unfortunately need to build a cross libc inbetween stage 1 and 2.) The specific kernel headers are more important when building your *libc as any change in the syscall area has a big effect on libc. Note that this part has settled down a long time ago and you can usually get away with a close-enough kernel here too. If you're not changing syscalls or other kernel headers then you can build your *libc once and forget it. workareas consist of: build kernel build *libc (rebuilding isn't needed that often) build everything else If you're not changing your libc or major changes in your kernel (that would effect *libc) you can build the libc and install it system wide along with gcc/bintuils. Also note, you need to make sure binutils and gcc dont look in /usr/include or /usr/lib by default, but instead uses your sys includes you build with and the libgcc.a, libiberty.a and libstdc++.a that you built. -- Dave ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
kernel headers question.
On the theory that I get lucky every so often ... :-)
We build embedded products. To do so we start by having to build the
cross-compilers, linkers, debuggers, i.e., the entire toolchain,
repeatedly for each developer. My job is to see if I can extract the
toolchain construction from each of the projects for purposes of
reuseability. Once a workspace is created, each developer will
construct his own copy of the toolchain in his own private workspace.
The thingy that does this build is something called buildroot. Also,
there's a library that gets built called UClibc. When the compiler, the
linker, UClibc are all built, the claim is that they are all tied to the
specific version of the kernel that will be embedded on the platform. IOW,
the UClibc is tied to the version of the kernel in use because of the
specific version of the kernel headers associated with the version of
linux in use. As you can see, the list of things that I would have to
manage is a multidimensional cube, where the axes are:
* The versions of linux for the project
* The versions of the compiler
* The versions of UClibc
* The versions of binutils.
It would be *very* nice to be able to eliminate the axis correspnding
to the version of linux.
(There may be more but this is enough to show the problem.)
It seems to me that we stopped using kernel headers a *long* time
ago, but I could be wrong. I am running Fedora Core 4 and I see that
I have glibc-kernheaders-2.4-9.1.94 installed even though I'm running
2.6.14-1.1653_FC4 of linux. (The contents of glibc-kernheaders is
confined to /usr/include/{asm,linux,mtd}.) I'm hoping this is doable
because I'm hard pressed to understand what things I would need to
worry about in userspace that would be kernel specific.
So having said all that, is it safe to say that for all versions of
2.4 and 2.6 series kernels, it's ok to have one old version of
glibc-kernheaders? Or is there some reason that I am constrained to
having seperate kernel headers for each project thereby necessitating
that each version of gcc, binutils, and UClibc is dependant on the
version of linux that it will run against?
TIA
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
