Re: Bug#2697: symlink /usr/include/asm in libc5-dev
> > They won't have to hack away in /usr/include. The kernel will
> > continue to ignore the headers in /usr/include and use its own, just
> > like it has for ages.
>
> I don't understand what you are saying here. For as long as I have been
> building kernels (not long, but many kernels) the proper completion of a
> kernel build relies on the correct connection of three symlinks:
> /usr/include/asm, /usr/include/linux, and /usr/src/linux.
> If I have not misunderstood this discussion, the libc5 installation
> interferes with the two /usr/include links (at least /usr/include/linux)
> which might break future kernel builds.
> When I get a new kernel, and re-make these symlinks, aren't the programs
> that rely on the libc5 setup going to fail to build behind the now broken
> libc5 links? Why can't libc5 rely on the natural placement of these
> header files, or at least verify that they are there before it breaks
> them (avoiding the break if they are there is preferable)
Take a look at the top-level, kernel Makefile. You'll see the
following lines.
TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi)
HPATH = $(TOPDIR)/include
HOSTCC =gcc -I$(HPATH)
CC =$(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
These lines accomplish two things. First, the TOPDIR part means you
don't have to put your kernel source in /usr/src/linux. You can put
it anywhere. For example, I put mine in /usr/src/linux-X.Y.Z.
Second, the HPATH part means that the headers that came with that
kernel are used instead of the ones in /usr/include/{asm,linux}. I've
been doing it this way on my system for >9 months. Believe me, it
works.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: