From: "Svetoslav Slavtchev" <svetljo@gmx.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: PATCH: drop symbolink link to kernel headers
Date: Thu, 22 Jan 2004 17:24:02 +0000 [thread overview]
Message-ID: <32043.1074792242@www1.gmx.net> (raw)
In-Reply-To: <5701.1074622084@www46.gmx.net>
> 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
next prev parent reply other threads:[~2004-01-22 17:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-20 18:08 PATCH: drop symbolink link to kernel headers Svetoslav Slavtchev
2004-01-21 23:53 ` Greg KH
2004-01-22 0:40 `
2004-01-22 1:51 `
2004-01-22 3:42 ` Dave Dodge
2004-01-22 17:06 ` linas
2004-01-22 17:24 ` Svetoslav Slavtchev [this message]
2004-01-22 17:28 ` Greg KH
2004-01-22 17:31 ` Greg KH
2004-02-03 0:52 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32043.1074792242@www1.gmx.net \
--to=svetljo@gmx.de \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).