[MPlayer-users] Compile with new kernel

[Gábor Lénárt]

On Thu, Jul 31, 2003 at 02:56:16PM -0400, D Richard Felker III wrote:
> No, that error has nothing to do with glibc. The exact same error
> would happen if glibc had been compiled against the new 2.6 test
> kernel. At first glance, it appears to me to be a bug in the 2.6
> version of fb.h -- it's including another kernel header without
> checking #ifdef __KERNEL__.
> 
> > You can't deny this fact: this is a sympthom of the fault of your
> > logic :)
> 
> No, Gabu is correct about kernel headers/libc.
> 
> > And how said that kernel should be at /usr/src/linux?
> 
> That's the standard location, but it's irrelevant. The point is that

Why? First of all, /usr should be suitable for read-only mounting, so
the whole /usr/src idea is broken (usually I have /var/src instead).
According to FHS /usr should be used via NFS or even from cdrom (ro),
so it's simply silly if you want to compile a new kernel with /usr/
on a cdrom ;-) FHS also says that /usr/src can contain any non-local
source. But what's up if /usr is NFS mounted on several computers
from the same server but these machines are using different kernels (so
kernel source here is LOCAL for those computers)?
But it's true that FHS is not so clear in some cases (maybe here too).
Also if you're using a binary distro, you may NOT have any kernel source
at all (OK, not fair, you can say here, that in that case /usr/include/linux
will contain the kernel headers from the kernel which was compiled as the
default kernel of the distro or such).


Also from FHS:

   These symbolic links are required if a C or C++ compiler is installed and
   only for systems not based on glibc.

     /usr/include/asm -> /usr/src/linux/include/asm-<arch>
     /usr/include/linux -> /usr/src/linux/include/linux

Note, for "only for systems not based on glibc".

Also from FHS about /usr/src:

   For systems based on glibc, there are no specific guidelines for this
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   directory. For systems based on Linux libc revisions prior to glibc, the
   following guidelines and rationale apply:

   The only source code that should be placed in a specific location is the
   Linux kernel source code. It is located in /usr/src/linux.

Debian follows FHS so maybe this is one reasion why /usr/include/linux/*
header files are came from libc6-dev and NOT from the actual kernel.

Also:

   Note: /usr/src/linux may be a symbolic link to a kernel source code tree.

     * BEGIN RATIONALE
     * It is important that the kernel include files be located in
       /usr/src/linux and not in /usr/include so there are no problems when
       system administrators upgrade their kernel version for the first time.
     * END RATIONALE


> /usr/include/linux should not be some outdated kernel headers that
> came with your distro, but the latest kernel you're actually using.
> Whether you make a symlink, compy each time you upgrade kernel, or
> whatever...


>From linux gazette:

   (!) [Mike] This is the normal Linux convention. Actually, you can place
   your build tree anywhere, but you should make /usr/src/linux a symlink to
   it so that the compiler will find the include files.

     (!) [Michal] Actually no, you SHOULDN'T!! Please do not spread an
     incorrect information in TAG or Linus will come and will haunt you for
     the rest of your lives.

   I'll spare the readership the flame war on his flight into hyperbole. --
   Heather

   (!) [Mike] (Is this [headers in /usr/src/linux/include/] still required
   now that glibc has its own kernel headers?)

     (!) [Michal] Headers in /usr/include/linux are "private" but these
     should be those headers which were used in a compilation of your
     libraries (notably glibc) and hacking around the with a link in /usr/src
     is a mistake as Linus tried to explain many times - sometimes quite
     forcibly. Headers used in a kernel compilation are NOT searched for in
     subdirectories of /usr/src/linux but are specific to a kernel version
     and can be drastically different between different versions, or at least
     you do not have any guarantees that they are not. If you happen to have
     sources to one of 2.2 kernels and one of 2.4 then /usr/src/linux link is
     supposed to mean what?

And some more info:

     (!) [Breen] That does seem to be THE official answer.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     From the 2.4.0 release, in linux/README:

 INSTALLING the kernel:

 - If you install the full sources, put the kernel tarball in a
 directory where you have permissions (eg. your home directory) and
 unpack it:
 gzip -cd linux-2.4.XX.tar.gz | tar xvf -

 Replace "XX" with the version number of the latest kernel.

 Do NOT use the /usr/src/linux area! This area has a (usually
 incomplete) set of kernel headers that are used by the library header
 files.  They should match the library, and not get messed up by
 whatever the kernel-du-jour happens to be.

     Some source packages indeed search for /usr/src/linux for configuration
     purposes. If this is not just a default which could, and should, be
     adjusted then they are simply wrong. Current 2.2 kernels will install
     'build' link in its /lib/modules subdirectory to indicate where sources
     for a given version are/were. This is not a foolproof either but still
     better than alternatives.

[...]

   (!) [Mike] None of my systems have ever had a /usr/src/linux directory at
   all. (Otherwise, I would not have been able to make the symlink without
   erasing stuff first.)

>From FAQ of linux from stracth:

6.11.3. Why we copy the kernel headers and don't symlink them

   In the past it was common practice to symlink the /usr/include/{linux,asm}
   directories to /usr/src/linux/include/{linux,asm}. This was a bad
   practice, as the following extract from a post by Linus Torvalds to the
   Linux Kernel Mailing List points out:

    - not have a single symbolic link in sight (except the one that the
      kernel build itself sets up, namely the "linux/include/asm" symlink
      that is only used for the internal kernel compile itself)

   And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
   header files, even though I haven't run a 2.2.13 kernel in a _loong_
   time. But those headers were what glibc was compiled against, so those
   headers are what matches the library object files.

SO MAYBE IF YOU THINK YOU'RE RIGHT, LINUS TORVALDS SEEM TO BE MORE STUPID
THEN YOU? ;-))) FSH, Linux gazette etc also? ;-))))))

This symlinking is an OLD and OUTDATED habbit, PLEASE GET IT NOW!




> 
> > I have several kernels, and not even /usr/src/linux directory. So where
> > can you symlink then? :) And if you're using multiple kernels, let's say
> > a 2.4.x for daily work, and 2.6.0-test2 for testing? You should relink
> > /usr/include/linux each time you boot into a new kernel? ;-)
> 
> If 2.6 headers weren't broken then it should definitely be 2.6.
> Building against newer kernel headers should not cause problems when
> running on an older kernel, except some ioctl's might not be available
> (and thus they will gracefully fail). On the other hand, building
> against old kernel headers will prevent using new features (like
> v4l2).

Okey, but I can compile and use mplayer on 2.6.0 while you not :)
Sure, if some 2.6 related function should be used by your program in
case of fb, or if binary comaptibility is not provided, then this thing
would become more complex. This may be the reason why libc needs
even variables to assume a kernel version etc ...

But beleive or not, I thing glibc is becoming a real monster and IMHO
it would be better to have something smaller, cleaner, etc but now we
have got glibc now. OK, there're several libc projects, but afaik they
don't get the same stability and compatibility with existing binariy
executables I need. But feel free to announce a new libc project for
mplayer: mplayerlibc :) Seriously, glibc is a bit mess nowdays. But
it's not up to me (and not up to you, unless you're a glibc developer;
I'm not ...).

Using video4linux API v2 is another issue, where you're using a feature
again which is NOT glibc related so you should use kernel headers
DIRECTLY FROM THE SOURCE, and NOT from /usr/include/linux.

> > The correct policy: for "normal" user space programs you should include
> > from /usr/include/linux which is kernel headers glibc was compiled against,
> > and specify the ABSOLUTE path of withing kernel source if you depend on
> > a certain kernel, the desired method is to add the following path to
> > eg -I switch of gcc:
> 
> WTF is this obsession with glibc??? If glibc really depends on kernel
> headers, then it needs to be *fixed* (or better yet replaced with a
> libc that doesn't grow exponentially with each release, e.g. uclibc).
> In any case, if there is such a problem, it's a bug in glibc.

No, I mean, if YOUR program requires it, eg you're writing kernel module
or whatever, so you really need the (current) kernel's things.

> Anyway, like both Gabu and I said, we have not seen such a problem in
> 6 years of compiling everything from source, so I don't believe the
> problem actually exists. If you insist that it does, perhaps you could
> enlighten us by showing us the particular struct
> definitions/prototypes/whatever that conflict...

I like people like you; do you really think that you're more clever than
all of the Debian and/or kernel developers? Of curse my opinion is not
come from my dreams but it's learnt from people whose knowledge on topic
is not comparable with mine :)

But I don't want to continue this flame topic, please be happy with yout
myths, I don't want to break of your religion :)

> No, you would have to recompile glibc to use new kernel features (like
> fb after upgrading from linux 2.0 to 2.2) if you insist on keeping the
> kernel headers 'in sync' with your glibc. This is dumb.

Sure, you have got some truth here, but please think a bit about it:
if you want to use new features which are more kernel related (fb is nothing
with glibc) you CAN use kernel headers, but you SHOULD include with
absolute path, this is why /lib/modules/(kernel-version)/build is guessed
for. But the topic is more general here, it's about the origin of
/usr/include/linux/* header files and such. Of course the same, if you're
building a kernel module, sure it's nothing about glibc. Also with fb
example, in this situation you want to use a feature (framebuffer) which
is NOT a glibc realted stuff. BUT. If you compile against older kernel
headers (I mean an fb app), that should compile and WORK, _IF_ binary
compatible with kernel is provided among different kernel versions.
If not, it's bad, since that means, older compiled softwares will fall
to work the new kernel as well! So the situation is a bit complicated
here.

> > Gabu, as you know I like you :), but please do not argue, I think I know
> > much more about kernel than you :) It's a pointless argument, and you try to
> > show your truth with jokes and hypes, but not actual technical facts ...
> 
> This isn't a kernel issue but a userspace/libc issue, so it doesn't
> matter who knows more about the kernel.

It does not such a simple thing that you may assume, not even clear, so
you should not make such a decision. framebuffer is not only a user space
thing as well, and the topic started at framebuffer.

Though I think I've commited a fault in this thread (yes, really ;-) ->
the topic was started with compilation a program (mplayer) which uses
framebuffer, then it formed into another topic: the header issue. I should
have not mix these topic, because they're not the same, or even maybe
you're right somewhere when I'm thinking about the header issue, and you
about the framebuffer compilation issue vice versa. So the flame can be
also my fault, sorry for the missleading.

But my opinion about the headers issues (in the view of a normal user
space issue) is true ;-)

- Gábor (larta'H)