Kernel build headers [was: Re: problems about __cli()]

Kernel build headers [was: Re: problems about __cli()]

[Iain Sandoe]

Since, I don't actually have a problem with finding the __cli() function
;-))

My installation was based on LinuxPPC 1999 Q3.  I decided to re-try the
actions that caused me to make my rash "vital" statement (as I said I'm not
immune from 'finger trouble' :-)

===

OK - I deleted the "linux" symlink in /usr/src (let's not get hung up about
where the kernel sources actually reside - I accept that con be anywhere one
chooses)....

On 2.2.17pre10 (having done a make mrproper, menuconfig, dep):

[root@athena stable-dma-int]# make vmlinux
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
scripts/split-include scripts/split-include.c
In file included from /usr/include/errno.h:36,
                 from scripts/split-include.c:26:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory

On 2.4.0-test4 (just to see if the build script makes *any* difference):

[root@athena linux-2.4.0-t4-wrk]# make vmlinux
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
scripts/split-include scripts/split-include.c
In file included from /usr/include/errno.h:36,
                 from scripts/split-include.c:26:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory

more below ====>>>

 Sat, Jul 22, 2000,  Martin Costabel wrote:
> Geert Uytterhoeven wrote:
>>
>> On Thu, 20 Jul 2000, Josh Huber wrote:
>>
>> You don't have to put your kernel in /usr/src, and you DON'T have to
>> symlink /usr/src/linux to it before you build.  The symlinks (on
>> broken RedHat derivatives) in /usr/include should point to the kernel
>> headers that your libc was built againt, otherwise you risk breaking
>> binary compatibility.
>
> This is an argument I have heard several times, but I never understood:
> If this risks breaking binary compatibility, then your kernel (compiled
> with its own headers, after all) might not be binary compatible with
> your glibc. Not nice.

So, if you are (habitually) building different kernels what *is* the right
solution?  Point to the source for the delivered kernel? (this won't work if
you make new headers in asm-ppc BTW) Point to the current source? Maintain
several parallel installations? (not sure how practical that is)...

>> > On Thu, Jul 20, 2000 at 02:45:56PM +0100, Iain Sandoe wrote:
>> > > I guess I *must* have one of those broken derivatives... and it doesn't
work
>> > > for me without that step...  Admittedly, this is mostly an issue between
>> > > 2.2.xx and 2.4.0 - but I do have to remember to change it back between
>> > > whiles... a better way would be ?
>> >
>> > Well...hmm, what doesn't work?  You mean you can't build a kernel
>> > unless you make /usr/src/linux point to the kernel source you're
>> > building?  This is odd, as I haven't done that...ever!  In fact,
>> > there's no directories in /usr/src on my machine.
>>
>> IIRC, there was a time (long before 2.0) that kernel builds did look for
>> includes in /usr/include/, so you had to unpack (or symlink) your kernel in
>> /usr/src/linux/. Fortunately the include path was changed to put
>> root_of_build/include first.
>
> There *are* situations where you need /usr/src/linux to point to your
> current kernel sources. This is when you compile modules for the current
> kernel, a prominent example being MOL.

Also, as I am doing, if you have a user-land program that accesses a
kernel-maintained structure via a syscall - the layout of the kernel
structure is (properly) defined in a header in linux/include/asm - but you
also need to get at it when compiling the user-land program.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Kernel build headers [was: Re: problems about __cli()]

[Michel Dänzer]

Iain Sandoe wrote:

> [root@athena stable-dma-int]# make vmlinux
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include scripts/split-include.c
> In file included from /usr/include/errno.h:36,
>                  from scripts/split-include.c:26:
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
>
> On 2.4.0-test4 (just to see if the build script makes *any* difference):
>
> [root@athena linux-2.4.0-t4-wrk]# make vmlinux
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include scripts/split-include.c
> In file included from /usr/include/errno.h:36,
>                  from scripts/split-include.c:26:
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory

You are lacking the glibc header files. On my Debian potato system I have:

> dpkg -S linux/errno.h
libc6-dev: /usr/include/linux/errno.h


Michel


--
What do you mean, my birth certificate expired?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Kernel build headers [was: Re: problems about __cli()]

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

On Mon, Jul 24, 2000 at 09:11:08AM +0100, Iain Sandoe wrote:
> On 2.2.17pre10 (having done a make mrproper, menuconfig, dep):
> 
> [root@athena stable-dma-int]# make vmlinux
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include scripts/split-include.c
> In file included from /usr/include/errno.h:36,
>                  from scripts/split-include.c:26:
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory

The reason this is failing is split-include isn't part of the kernel,
it's part of the build process and is a regular user-space binary,
which should be including the header files that your libc was built
against.

> So, if you are (habitually) building different kernels what *is* the right
> solution?  Point to the source for the delivered kernel? (this won't work if
> you make new headers in asm-ppc BTW) Point to the current source? Maintain
> several parallel installations? (not sure how practical that is)...

Ok, in the case of redhat systems which use the symlinks, they should
point to /usr/src/linux/include/{linux,asm,etc}, and /usr/src/linux
should point to /usr/src/kernel_that_shipped_with_distro

IMHO, you should never have to change this setup, unless perhaps you
rebuild libc against a newer kernel.

Please read this:
http://www.debian.org/Lists-Archives/debian-policy-9907/msg00182.html

This is a good explanation as to why pointing the symlinks to the
newest kernels can be bad sometimes by Linus.  He makes some good
points, and can discribe the situation better than me :)  Also, he
explains why building a new kernel against it's own (newer) header
files does NOT break binary compatibility, but building user space
programs against new header files, without a new libc will (sometimes)
break things.

> Also, as I am doing, if you have a user-land program that accesses a
> kernel-maintained structure via a syscall - the layout of the kernel
> structure is (properly) defined in a header in linux/include/asm - but you
> also need to get at it when compiling the user-land program.

In this case you should ship the corresponding header files that your
user space program uses with that user-space utility.  This makes sure
that it gets things right and doesn't depend on having a kernel tree
around that you know the location of.  For example, for a program I'm
working with, which uses an ioctl interface on a /dev entry (used to
use system calls, but switched), I've set up a directory tree like:
src    all the code
include
    linux  header files copied from the kernel tree (just the ones I
           need)
    other header files

This way, when autoconf places a -Ibuild_root/include with each
compile, it uses the local header files.

Before I did this, building was hell -- it's SO much better being able
to build the user-space code on any box without having to untar kernel
source.

Again, just my opinion, but I've found that this works very well.

I believe in general, unless the program you're writing needs to track
the kernel very closely, it's bad practice to include kernel headers
in user-space code.

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: Kernel build headers [was: Re: problems about __cli()]

[Iain Sandoe]

On Mon, Jul 24, 2000, Josh Huber wrote:
> On Mon, Jul 24, 2000 at 09:11:08AM +0100, Iain Sandoe wrote:
>> On 2.2.17pre10 (having done a make mrproper, menuconfig, dep):
[snip]

Thanks for the info. read & understood... guess I'll have to continue this
way until my distro settles into the new way (or I have time to change
distro)...

>> Also, as I am doing, if you have a user-land program that accesses a
>> kernel-maintained structure via a syscall - the layout of the kernel
>> structure is (properly) defined in a header in linux/include/asm - but you
>> also need to get at it when compiling the user-land program.
>
> In this case you should ship the corresponding header files that your
> user space program uses with that user-space utility.  This makes sure
> that it gets things right and doesn't depend on having a kernel tree
> around that you know the location of.  For example, for a program I'm
> working with, which uses an ioctl interface on a /dev entry (used to
> use system calls, but switched), I've set up a directory tree like:
> src    all the code
> include
>     linux  header files copied from the kernel tree (just the ones I
>            need)
>     other header files
>
> This way, when autoconf places a -Ibuild_root/include with each
> compile, it uses the local header files.
>
> Before I did this, building was hell -- it's SO much better being able
> to build the user-space code on any box without having to untar kernel
> source.
>
> Again, just my opinion, but I've found that this works very well.
>
> I believe in general, unless the program you're writing needs to track
> the kernel very closely, it's bad practice to include kernel headers
> in user-space code.

Well, the user space prog. (posting due in about an hour ;-) is mainly for
kernel/driver developers so they would naturally need to track the two
together - I'm entirely in agreement that it is a bad idea to have general
user programs that require kernel sources :-)

Thanks,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/