l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2004 Jul 25 09:17

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Debian configuration: X and modem and zip]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Debian configuration: X and modem and zip]



Quoting Mark K. Kim (lugod@cbreak.org):

> If that's incorrect, then the NVidia people needs to get their acts
> straight 'cuz their proprietary X server requires /usr/src/linux/include.

There's still a lot of fairly broken proprietary software out there that
hasn't gotten the word.  (But see below.)

> In either case, it doesn't hurt to have kernel headers in the kernel
> source directory.  

Not as _such_.  What hurt are kernel headers used for _general_ compiles
being out of step with the installed libc.  

> If the application uses it, then it uses it, and I'm sure there's a
> reason for using it if the programmers knew what they were doing, and
> if it doesn't use it, then it doesn't use it.

If Nvidia claims to need those symlinks, then set them -- but then it
might be wise to remove them immediately afterwords, since, unless those
kernel headers in /usr/src/linux/include happen to be the same as the
regular ones in /usr/include/linux, you're might hurt your ability to
compile anything else -- a problem that will worsen over time as you
install newer kernel source trees (and thus newer kernel headers) in
/usr/src/linux.  Back in the day, that's what started to happen to my
system as I started using new kernel source trees, and the compilation
errors were very bewildering.  (See below, however, about why this
syndrome happens only if your system has some funny stuff going on
inside /usr/include -- which yours may well not have.)

> BTW, something to ponder:
> 
>   http://lugod.org/mailinglists/archives/vox-tech/2003-01/msg00090.html

In which you start with:

> Basically, Linus was arguing it's okay for a binary using an old
> kernel header to interact with the newer kernel or a newer library,
> but not the other way around, right?

No.  Pardon me for a moment while I review the topic for my own benefit
(so *I* don't get confused):  Some standard header files are used as
entry point to certain library routines.  We're talking about the header
files that on modern systems live in these subdirectories:

/usr/include/linux
/usr/include/asm
/usr/include/scsi

Those installed headers are in sync with your installed glibc and other
key system libs.

The old way of doing things, that Torvalds was complaining about, was to 
replace those three (appropriate, usable) directories with symlinks, as
follows:

/usr/include/linux  ->  /usr/src/linux/include/linux
/usr/include/asm    ->  /usr/src/linux/include/asm
/usr/include/scsi   ->  /usr/src/linux/include/scsi

Kernel tarballs actually had instructions in their README files
requiring the user to set the above symlinks[1], after unpacking the
kernel, which would go like this:

# cd /usr/src
# tar xvzf /tmp/linux-1.2.13.tar.gz
# mv linux linux-1.2.13    # because, then, the tarball unpacked to "linux"
# ln -s linux-1.2.13  linux
# cd linux

...and you'd be (finally) ready to do kernel or other compiles -- which
would work OK at first, but start to go seriously wonky by the time you 
were doing this:

# cd /usr/src
# rm linux
# tar xvzf /tmp/linux/2.2.25.tar.gz
# mv linux linux-2.2.25
# ln -s linux-2.2.25  linux
# cd linux

...since, at that point, the headers you were referencing during
compiles (inside /usr/src/linux/include) were severely out of whack with
the installed libc.

That's the "symlink insanity".  Torvalds wasn't complaining about
/usr/src/linux per se, but rather the effect of that symlink in conjunction 
with the other three.

On a truly -=modern=- system, where /usr/include/linux,
/usr/include/asm, and /usr/include/scsi are no longer symlinks to
outside the /usr/include tree (to locations in /usr/src/linux), you can
safely put into locations in /usr/src/ anything you want, because the
general run of Makefiles aren't going to be hurt by automatically
derefencing to locations in that tree.   _If_ your system keeps its
system-level header references within /usr/include, then Nvidia can play
around in /usr/src to its heart's content.

But you should also be aware that, other than to make happy proprietary
vendors who haven't gotten the word yet, there's no longer anything
special about /usr/src/linux at all, and you're under no obligation to
compile your kernels there any more.

[1] And, in somewhat later kernel versions than that, one of the kernel
compile steps, probably "make dep", created those /usr/include-level 
symlinks automatically.

-- 
Cheers,
Rick Moen                                     Age, baro, fac ut gaudeam.
rick@linuxmafia.com
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.