PATCH: drop symbolink link to kernel headers

PATCH: drop symbolink link to kernel headers

[Svetoslav Slavtchev]

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

Hi,
the attached patch removes the need from a symbolik link to kernel headers
when compiling against klibc.
if KERNEL_DIR is not specified it looks for kernel headers
in /usr/src/linux( of course you could change it to /lib/modules/`uname
-r`/build )

the main idea is to build packages a bit easier/ pretier
instead of creating a symbolik link, one can specify
make KERNEL_DIR=[path to kernel] or omit it in case
kernel sources are available in /usr/src/linux

best,
svetljo

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: udev013_klibc_kheaders.diff --]
[-- Type: text/x-patch; name="udev013_klibc_kheaders.diff", Size: 2962 bytes --]

diff -Naurb udev-013/extras/multipath/libdevmapper/Makefile udev.old/extras/multipath/libdevmapper/Makefile
--- udev-013/extras/multipath/libdevmapper/Makefile	2003-12-10 12:14:19.000000000 +0100
+++ udev.old/extras/multipath/libdevmapper/Makefile	2004-01-19 12:29:13.153889468 +0100
@@ -10,7 +10,7 @@
 GCCINCDIR := ${shell $(CC) -print-search-dirs | sed -ne "s/install: \(.*\)/\1include/gp"}
 CFLAGS = -pipe -g -O2 -Wall -Wunused -Wstrict-prototypes -nostdinc \
          -I$(klibcdir)/klibc/include -I$(klibcdir)/klibc/include/bits32 \
-         -I$(GCCINCDIR) -I$(klibcdir)/linux/include -I. -Iioctl
+         -I$(GCCINCDIR) -I$(KERNEL_DIR)/include -I. -Iioctl
 
 OBJS = ioctl/libdevmapper.o libdm-common.o
 
diff -Naurb udev-013/extras/multipath/Makefile udev.old/extras/multipath/Makefile
--- udev-013/extras/multipath/Makefile	2004-01-05 20:48:32.000000000 +0100
+++ udev.old/extras/multipath/Makefile	2004-01-19 12:34:49.127502355 +0100
@@ -15,7 +15,7 @@
 GCCINCDIR := ${shell $(CC) -print-search-dirs | sed -ne "s/install: \(.*\)/\1include/gp"}
 CFLAGS = -pipe -g -O2 -Wall -Wunused -Wstrict-prototypes -nostdinc \
          -I$(klibcdir)/klibc/include -I$(klibcdir)/klibc/include/bits32 \
-         -I$(GCCINCDIR) -I$(klibcdir)/linux/include -I$(sysfsdir) -I.
+         -I$(GCCINCDIR) -I$(KERNEL_DIR)/include -I$(sysfsdir) -I.
 
 OBJS = main.o
 CRT0 = ../../klibc/klibc/crt0.o
@@ -32,7 +32,7 @@
 
 recurse:
 	@for dir in $(SUBDIRS); do\
-	$(MAKE) -C $$dir ; \
+	$(MAKE) KERNEL_DIR=$(KERNEL_DIR) -C $$dir ; \
 	done
 	$(MAKE) $(EXEC)
 
diff -Naurb udev-013/klibc/MCONFIG udev.old/klibc/MCONFIG
--- udev-013/klibc/MCONFIG	2004-01-19 13:26:01.115895297 +0100
+++ udev.old/klibc/MCONFIG	2004-01-18 16:59:06.047625766 +0100
@@ -12,7 +12,7 @@
 	  -I$(KLIBSRC)/arch/$(ARCH)/include \
 	  -I$(KLIBSRC)/include/bits$(BITSIZE) \
 	  -D__KLIBC__ -DBITSIZE=$(BITSIZE) -I$(KLIBSRC)/include \
-	  -I$(SRCROOT)/linux/include
+	  -I$(KERNEL_DIR)/include
 LDFLAGS =
 AR      = $(CROSS)ar
 RANLIB  = $(CROSS)ranlib
diff -Naurb udev-013/Makefile udev.old/Makefile
--- udev-013/Makefile	2004-01-19 13:26:01.115895297 +0100
+++ udev.old/Makefile	2004-01-19 12:36:13.173255316 +0100
@@ -32,6 +32,10 @@
 LOCAL_CFG_DIR =	etc/udev
 
 DESTDIR =
+ifndef KERNEL_DIR
+KERNEL_DIR=/usr/src/linux
+endif
+
 # override this to make udev look in a different location for it's config files
 prefix =
 exec_prefix =	${prefix}
@@ -122,7 +126,7 @@
 	KLIBC_BASE	= $(PWD)/klibc
 	KLIBC_DIR	= $(KLIBC_BASE)/klibc
 	INCLUDE_DIR	:= $(KLIBC_DIR)/include
-	LINUX_INCLUDE_DIR	:= $(KLIBC_BASE)/linux/include
+	LINUX_INCLUDE_DIR	:= $(KERNEL_DIR)/include
 	include $(KLIBC_DIR)/arch/$(ARCH)/MCONFIG
 	# arch specific objects
 	ARCH_LIB_OBJS =	\
@@ -150,7 +154,7 @@
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
 		$(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
-			-C $$target $@ ; \
+			KERNEL_DIR="$(KERNEL_DIR)" -C $$target $@ ; \
 	done ; \
 
 $(ROOT): $(LIBC)

Re: PATCH: drop symbolink link to kernel headers

[Greg KH]

On Tue, Jan 20, 2004 at 07:08:04PM +0100, Svetoslav Slavtchev wrote:
> Hi,
> the attached patch removes the need from a symbolik link to kernel headers
> when compiling against klibc.
> if KERNEL_DIR is not specified it looks for kernel headers
> in /usr/src/linux( of course you could change it to /lib/modules/`uname
> -r`/build )

It's a nice idea, but is it really needed?

No one should be putting their kernel code in /usr/src/linux, so that's
just a bad thing to start with.  /usr/src/linux points to the version of
linux that your glibc was built against, that is all.

> the main idea is to build packages a bit easier/ pretier
> instead of creating a symbolik link, one can specify
> make KERNEL_DIR=[path to kernel] or omit it in case
> kernel sources are available in /usr/src/linux

Does the current situation really cause that much of a problem in
building packages?

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[@ 2004-01-22 0:40 UTC (permalink / raw)]

Greg KH <greg@kroah.com> writes:

> No one should be putting their kernel code in /usr/src/linux, so that's
> just a bad thing to start with.  /usr/src/linux points to the version of
> linux that your glibc was built against, that is all.

No, that's /usr/include/{linux,asm} you're thinking of. They should be
_copies_ of the kernel headers glibc was built against, and not symlinks
to /usr/src/linux/{include,asm}. /usr/src/linux can be whatever you
like, and third-party, out-of-three modules tend to look there (after
/lib/modules/$(uname -r)/build and /usr/src/linux-$(uname -r)) for the
current kernel headers.

-- 
ilmari



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[@ 2004-01-22 1:51 UTC (permalink / raw)]

ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> third-party, out-of-three modules
                      ^^^^^
                      tree, obviously

-- 
ilmari



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[Dave Dodge]

On Thu, Jan 22, 2004 at 01:40:50AM +0100, Dagfinn Ilmari Manns?ker wrote:
> Greg KH <greg@kroah.com> writes:
> > No one should be putting their kernel code in /usr/src/linux, so that's
> > just a bad thing to start with.  /usr/src/linux points to the version of
> > linux that your glibc was built against, that is all.
> 
> No, that's /usr/include/{linux,asm} you're thinking of. They should be
> _copies_ of the kernel headers glibc was built against, and not symlinks
> to /usr/src/linux/{include,asm}. /usr/src/linux can be whatever you like,

True. But because of past misbehavior by distributions and glibc, leading
to the sort of confusion above about what might be found in /usr/src/linux,
you should really avoid using /usr/src/linux for anything at all.

Since at least early 2.4 the kernel README has explictly stated that
kernels should not be placed in /usr/src/linux.

> and third-party, out-of-tree modules tend to look there

I'm sure they do. But that doesn't mean they should :-)

                                                  -Dave Dodge


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[linas]

On Thu, Jan 22, 2004 at 02:51:29AM +0100, Dagfinn Ilmari Manns?ker wrote:
> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> 
> > third-party, out-of-three modules
>                       ^^^^^
>                       tree, obviously

Oh, and I thought that was a witty way to say "three out of three 
third parties" ... 

I once used a third-party, proprietary ide driver (rocketraid 404)
that installed itself in /usr/src/linux instead of /lib/modules.
Then one day I rm -r'ed /usr/src/linux ... and never booted that 
machine again.

--linas


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[Svetoslav Slavtchev]

> On Tue, Jan 20, 2004 at 07:08:04PM +0100, Svetoslav Slavtchev wrote:
> > Hi,
> > the attached patch removes the need from a symbolik link to kernel
> headers
> > when compiling against klibc.
> > if KERNEL_DIR is not specified it looks for kernel headers
> > in /usr/src/linux( of course you could change it to /lib/modules/`uname
> > -r`/build )
> 
> It's a nice idea, but is it really needed?

well, i could always patch it :-)
and may be other packagers too,
but i think it's a good idea


> No one should be putting their kernel code in /usr/src/linux, so that's
> just a bad thing to start with.  /usr/src/linux points to the version of
> linux that your glibc was built against, that is all.

every distribution( at least the major ones) do have a package kernel source
which does install in /usr/src/linux-[version] and put's a symlink
/usr/src/linux
( and /lib/modules/`uname -r`) to it
from my experiance i can say this is true for Mandrake, RedHat, SuSE
and i think Debian too

and most if not all external modules do check for kernel headers
in the above locations( and not only modules, but also programs
e.g. iptables, dvb  apps.)
 
> > the main idea is to build packages a bit easier/ pretier
> > instead of creating a symbolik link, one can specify
> > make KERNEL_DIR=[path to kernel] or omit it in case
> > kernel sources are available in /usr/src/linux
> 
> Does the current situation really cause that much of a problem in
> building packages?
> 

it's not a trouble, but IMHO it's a bit ugly to create symlink to kernel
source
in the package build 

best,

svetljo

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[Greg KH]

On Thu, Jan 22, 2004 at 01:40:50AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > No one should be putting their kernel code in /usr/src/linux, so that's
> > just a bad thing to start with.  /usr/src/linux points to the version of
> > linux that your glibc was built against, that is all.
> 
> No, that's /usr/include/{linux,asm} you're thinking of. They should be
> _copies_ of the kernel headers glibc was built against, and not symlinks
> to /usr/src/linux/{include,asm}.

Ah yes, you are correct.  Got that mixed up...

> /usr/src/linux can be whatever you like, and third-party, out-of-three
> modules tend to look there (after /lib/modules/$(uname -r)/build and
> /usr/src/linux-$(uname -r)) for the current kernel headers.

But /lib/modules/`uname -r`/build is much better than defaulting to
/usr/src/linux

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[Greg KH]

On Thu, Jan 22, 2004 at 06:24:02PM +0100, Svetoslav Slavtchev wrote:
> > On Tue, Jan 20, 2004 at 07:08:04PM +0100, Svetoslav Slavtchev wrote:
> > > Hi,
> > > the attached patch removes the need from a symbolik link to kernel
> > headers
> > > when compiling against klibc.
> > > if KERNEL_DIR is not specified it looks for kernel headers
> > > in /usr/src/linux( of course you could change it to /lib/modules/`uname
> > > -r`/build )
> > 
> > It's a nice idea, but is it really needed?
> 
> well, i could always patch it :-)
> and may be other packagers too,
> but i think it's a good idea

Ok, how about defaulting to /lib/modules/`uname -r`/build instead.

Also, you don't have to check if KERNEL_DIR is set before trying to set
it yourself.  Make will handle this properly.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: PATCH: drop symbolink link to kernel headers

[Greg KH]

On Tue, Jan 20, 2004 at 07:08:04PM +0100, Svetoslav Slavtchev wrote:
> Hi,
> the attached patch removes the need from a symbolik link to kernel headers
> when compiling against klibc.
> if KERNEL_DIR is not specified it looks for kernel headers
> in /usr/src/linux( of course you could change it to /lib/modules/`uname
> -r`/build )
> 
> the main idea is to build packages a bit easier/ pretier
> instead of creating a symbolik link, one can specify
> make KERNEL_DIR=[path to kernel] or omit it in case
> kernel sources are available in /usr/src/linux

Ok, I've fixed up this patch, added documentation, and applied it.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel