Re: New course for Debian University
On Sat, Dec 30, 2000 at 02:50:56AM +, Rob VanFleet wrote: > > The gist I got from it was that the headers in /usr/src/linux should be those > headers that glibc was compiled against, regardless of what kernel you're > actually running. Like if you were running potato with the kernel upgraded to > 2.2.18, you should still have the source (or the headers, at least) to 2.2.17 > in /usr/src/linux. > > At least, that's what I thought, feel free to correct me. no the reason Linus says to leave /usr/src/linux alone is because he does not use debian, and pretty much every distro *except* debian has /usr/include/asm -> /usr/src/linux/include/asm and /usr/include/linux -> /usr/src/linux/include/linux, and the distribution then installs the kernel source to whatever kernel they ship with in /usr/src/linux. so if you remove /usr/src/linux you remove all the glibc headers which breaks your ability to compile ordinary programs. This is why Linus says just leave /usr/src/linux alone, its because distributions insist on having the broken /usr/include/ symlinks. since debian does not have these symlinks and does not even install any kernel source in /usr/src/linux this is all irrelevant on Debian. you can add a /usr/src/linux symlink on debian but it doesn't affect anything since /usr/include has no symlinks pointing there. where it *DOES* break things is redhat, and everything following redhat's lead. (iow, everything except debian and possibly slack) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpFn2y2j0nxZ.pgp Description: PGP signature
Re: New course for Debian University
On Fri, Dec 29, 2000 at 08:10:52PM +, Oliver Elphick wrote: > Brian Keck wrote: > >On the question of /usr/src/linux & symlinks, Linus sent a couple > >of messages to linux-kernel a few months ago ... > > > Yes, but these refer to the commonly found link from /usr/include/asm > into /usr/src/linux/include; that is the link that should not be there. > Linus is saying that the include files used to build glibc should also > be used to build any programs that call on glibc. > > (The second person Linus was answering had some confusion about the > links he was talking about -- confusion which Linus did not notice or > ignored.) > > I can see no harm at all in having a symbolic link from /usr/src/linux > to the actual kernel source directory. The gist I got from it was that the headers in /usr/src/linux should be those headers that glibc was compiled against, regardless of what kernel you're actually running. Like if you were running potato with the kernel upgraded to 2.2.18, you should still have the source (or the headers, at least) to 2.2.17 in /usr/src/linux. At least, that's what I thought, feel free to correct me. -Rob
Re: New course for Debian University
Brian Keck wrote: >On the question of /usr/src/linux & symlinks, Linus sent a couple >of messages to linux-kernel a few months ago ... Yes, but these refer to the commonly found link from /usr/include/asm into /usr/src/linux/include; that is the link that should not be there. Linus is saying that the include files used to build glibc should also be used to build any programs that call on glibc. (The second person Linus was answering had some confusion about the links he was talking about -- confusion which Linus did not notice or ignored.) I can see no harm at all in having a symbolic link from /usr/src/linux to the actual kernel source directory. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "But I say unto you, That every idle word that men shall speak, they shall give account thereof in the day of judgment." Matthew 12:36
Re: New course for Debian University
On the question of /usr/src/linux & symlinks, Linus sent a couple of messages to linux-kernel a few months ago ... Brian Keck --- Forwarded Messages >From [EMAIL PROTECTED] Thu Jul 27 17:49:26 2000 X-Authentication-Warning: palladium.transmeta.com: mail set sender to [EMAIL PROTECTED] using -f To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Linus Torvalds) Subject: Re: RLIM_INFINITY inconsistency between archs Date: 27 Jul 2000 00:39:51 -0700 Organization: Transmeta Corporation Message-Id: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Precedence: bulk X-Loop: [EMAIL PROTECTED] Content-Length: 4299 In article <[EMAIL PROTECTED]>, Boszormenyi Zoltan <[EMAIL PROTECTED]> wrote: > >/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the >original distribution but /usr/src/linux is a 2.4.0-testX tree. >With a 2.2.X source tree, it does not produce any warning. I've asked glibc maintainers to stop the symlink insanity for the last few years now, but it doesn't seem to happen. Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be. The fact is, that the header files should match the library you link against, not the kernel you run on. Think about it a bit.. Imagine that the kernel introduces a new "struct X", and maintains binary backwards compatibility by having an old system call in the old place that gets passed a pointer to "struct old_X". It's all compatible, because binaries compiled for the old kernel will still continue to run - they'll use the same old interfaces they are still used to, and they obviously do not know about the new ones. Now, if you start mixing a new kernel header file with an old binary "glibc", you get into trouble. The new kernel header file will use the _new_ "struct X", because it will assume that anybody compiling against it is after the new-and-improved interfaces that the new kernel provides. But then you link that program (with the new "struct X") to the binary library object archives that were compiled with the old header files, that use the old "struct old_X" (which _used_ to be X), and that use the old system call entry-points that have the compatibility stuff to take "struct old_X". Boom! Do you see the disconnect? In short, the _only_ people who should update their /usr/include/linux tree are the people who actually make library releases and compile their own glibc, because if they want to take advantaged of new kernel features they need those new definitions. That way there is never any conflict between the library and the headers, and you never get warnings like the above.. >Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard >"don't use kernel headers directly" answer. But neither gcc.c, >neither the above small program use kernel headers. I suppose he >referred to /usr/include/linux/* as (I think) he did not understand me. No. He really meant that you should not use the kernel headers: you should use the headers that glibc came with. It is probably a redhat bug that those headers were a symbolic link. I would suggest that people who compile new kernels should: - NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it. - compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to _install_ the kernel, but that's different. - 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. And this is actually what has been the suggested environment for at least the last five years. I don't know why the symlink business keeps on living on, like a bad zombie. Pretty much every distribution still has that broken symlink, and people still remember that the linux sources should go into "/usr/src/linux" even though that hasn't been true in a _loong_ time. Is there some documentation file that I've not updated and that people are slavishly following outdated information in? I don't read the documentation myself, so I'd never notice ;) Linus - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ --- Message 2 >From [EMAIL PROTECTED] Fri Jul 28 16:07:19 2000 X-Authentication-Warning: pe
Re: New course for Debian University
On Fri, Dec 29, 2000 at 10:21:30AM -0600, David A. Rogers wrote: > On Thu, 28 Dec 2000, Carel Fellinger wrote: > I understand your comment about fakeroot. However, I didn't include any > documentation on it for a couple of reasons. > > First, I've instructed the reader to read the kernel-package documentation > which includes instructions on how to do that already. As I state in the > University principles, I don't want to duplicate existing documentation if > possible. But elas, the info I've got on fakeroot is at least confusing:( At one place you're told to use "fakeroot command..." and somewhere else you'll find something like "command -use-fakeroot-option..." advertised as sometimes configure and friends don't work with fakeroot. And elas again I didn't manage to get the latter variant to work. In other words I just hoped to get better info at the university, like you did with modules. The info on modules *can* be found elsewere, but take a lot of digging. > Second, I really think that the use of fakeroot, in this case, is being > unnecessarily cautious. I agree that one should not login as root (normally), > but I see no harm in using su or sudo in an xterm window for the purpose of > building a new kernel - especially in light of the fact that my intended > audience is home users with dialup systems. They have a lot less security > risk (and need for security measures) than the average business box. > > I am open to discussion, however. If you can give me compelling reasons that > a home user should use fakeroot whilst building a kernel, please do. That might be, but on the other hand *especially* the audience you address is likely to be no expert, and hence should really be urged in all circum- stances to refrain from becomming root. Just a matter of consistent upbringing, not so much a security maesure in this case. > On the other topic, the kernel-package does state that > /usr/src/kernel-source-etc is an acceptable location for the kernel source. > If anyone can give a compelling reason not to make the linux symlink, I will > listen. In an other thread no-one came forth with such compelling reasons, so I think I remembered incorrectly and that link is alright after all. -- groetjes, carel
Re: New course for Debian University
Carel, Thanks for your input. I appreciate knowing what people think of the document. On Thu, 28 Dec 2000, Carel Fellinger wrote: > On Wed, Dec 27, 2000 at 08:12:05PM -0600, David A. Rogers wrote: > > Kernel 150 - Compiling the kernel - is open for enrollment (The Debian > > University document has been updated to include information on compiling the > > kernel in the Debian way). > > > > Debian University can be found at: > > > > http://home.xnet.com/~darogers/debian_university.txt > > Nice initiative. > Thanks. > > make-kpkg is very nice and makes compiling the kernel as easy as it can get > > I think it would be wise (and more debian like:) to explain how to > compile the kernel as *non* root using fakeroot. Furthermore I seem > to recall discussions on this list that it's better to refrain from > using/creating that /usr/src/linux link. I understand your comment about fakeroot. However, I didn't include any documentation on it for a couple of reasons. First, I've instructed the reader to read the kernel-package documentation which includes instructions on how to do that already. As I state in the University principles, I don't want to duplicate existing documentation if possible. Second, I really think that the use of fakeroot, in this case, is being unnecessarily cautious. I agree that one should not login as root (normally), but I see no harm in using su or sudo in an xterm window for the purpose of building a new kernel - especially in light of the fact that my intended audience is home users with dialup systems. They have a lot less security risk (and need for security measures) than the average business box. I am open to discussion, however. If you can give me compelling reasons that a home user should use fakeroot whilst building a kernel, please do. On the other topic, the kernel-package does state that /usr/src/kernel-source-etc is an acceptable location for the kernel source. If anyone can give a compelling reason not to make the linux symlink, I will listen. Cheers, dar
Re: New course for Debian University
On Thu, Dec 28, 2000 at 05:34:57PM -0600, Nathan E Norman wrote: > On Thu, Dec 28, 2000 at 05:05:30PM -0600, Rob VanFleet wrote: > > > I think there's confusion between making links in /usr/include and > > > links in /usr/src. The first is bad [0], the second is (afaik) not. > > > > Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, > > AFAIK, is not the issue. The module I tried to compiled looked for the > > kernel-includes in /usr/src/linux/include. I'm just wondering why > > /usr/src/linux is bad, and how to tell compiles to look somewhere other than > > /usr/src/linux. > > I'm not trying to be rude, but the only person saying the > /usr/src/linux symlink is bad is you (and you don't sound convinced :) Actually it was me who brought this up. And all I said was that I seemed to remember, so I'm not sure, could be something totally different, and elas, debian's archive's search doesn't work for the latest postings, so I can't easily check. But I did notice some posts where that very link (/usr/src/linux) was adviced as a remedy, and such posts didn't get angry follow-ups explaining how bad it is, so maybe it is just my rusty memory giving me problems he:) But I keep hearing this humming in the back of my head: /usr/src/linux symlink is trouble. Don't know where I picked it up though. -- groetjes, carel
Re: New course for Debian University
Rob VanFleet wrote: >In /usr/share/doc/kernel-package/README.gz: > > "...unpack your kernel somewhere. Preferably somewhere other than > /usr/src/linux..." > >It also adds "more on this later", but I found no explanation as to why, jus >t >some possible places to unpack the sources to, none of which are >/usr/src/linux. You may have several kernel source versions on your disk. You should point /usr/src/linux as a symbolic link to the one you are currently building. Do not download into it, because you then risk having 2 versions mixed together (or else create the new version directory and point /usr/src/linux to it just before you unpack the archive). If you load the Debian kernel-source... packages, each downloads into a different directory, with the appropriate name. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For God shall bring every work into judgment, with every secret thing, whether it be good, or whether it be evil." Ecclesiastes 12:14
Re: New course for Debian University
On Thu, Dec 28, 2000 at 05:34:57PM -0600, Nathan E Norman wrote: > I'm not trying to be rude, but the only person saying the > /usr/src/linux symlink is bad is you (and you don't sound convinced :) First of all, I'm *not* the only person saying that; I refer you to: http://lists.debian.org/debian-user-0012/msg04472.html Also, I never said I thought it was bad, I said I *heard* it was bad, and I'm curious that if it is, then why? -Rob
Re: New course for Debian University
On Thu, Dec 28, 2000 at 05:40:23PM -0600, Rob VanFleet wrote: > In /usr/share/doc/kernel-package/README.gz: > > "...unpack your kernel somewhere. Preferably somewhere other than > /usr/src/linux..." Unpacking implies a directory, which is not the same as a symlink. Don't worry about this. -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgp0MNBQIlc5c.pgp Description: PGP signature
Re: New course for Debian University
On Thu, Dec 28, 2000 at 05:05:30PM -0600, Rob VanFleet wrote: ... > Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, > AFAIK, is not the issue. The module I tried to compiled looked for the > kernel-includes in /usr/src/linux/include. I'm just wondering why > /usr/src/linux is bad, and how to tell compiles to look somewhere other than > /usr/src/linux. IIRC the argument was that you could be compiling for a different kernel, or even for a different machine. (Modules that are part of the kernel source are handled correctly without this link) That's all I know:( Perhaps debian-devel is a better place to hunt for intelligent opinions on this. -- groetjes, carel
Re: New course for Debian University
In /usr/share/doc/kernel-package/README.gz: "...unpack your kernel somewhere. Preferably somewhere other than /usr/src/linux..." It also adds "more on this later", but I found no explanation as to why, just some possible places to unpack the sources to, none of which are /usr/src/linux. -Rob On Thu, Dec 28, 2000 at 05:24:18PM -0600, Jon Pennington wrote: > Rob VanFleet wrote: > > > > Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, > > AFAIK, is not the issue. The module I tried to compiled looked for the > > kernel-includes in /usr/src/linux/include. I'm just wondering why > > /usr/src/linux is bad, and how to tell compiles to look somewhere other than > > /usr/src/linux. > > I read this just the other day (don't recall where; prolly on > kt.linuxcare.com). Making a symlink in /usr/include is BAD because > compiling apps against kernel headers different from the kernel headers > glibc was compiled against is BAD. Making a symlink from > /usr/src/linux-version to /usr/src/linux is NOT bad; I have never done > this any other way. > > -- > -=|JP|=-"Why, oh, why didn't I take the blue pill?" > Jon Pennington| Atipa Linux Solutions -o) > [EMAIL PROTECTED] | http://www.atipa.com/\\ > Kansas City, MO, USA | 816-595-3000 x1550 _\_V > > 6D04 39E0 CAE9 9ADA 2CA3 2EBE 898A 6C37 CA1E A29C > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New course for Debian University
On Thu, Dec 28, 2000 at 05:05:30PM -0600, Rob VanFleet wrote: > > I think there's confusion between making links in /usr/include and > > links in /usr/src. The first is bad [0], the second is (afaik) not. > > Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, > AFAIK, is not the issue. The module I tried to compiled looked for the > kernel-includes in /usr/src/linux/include. I'm just wondering why > /usr/src/linux is bad, and how to tell compiles to look somewhere other than > /usr/src/linux. I'm not trying to be rude, but the only person saying the /usr/src/linux symlink is bad is you (and you don't sound convinced :) I've never heard that a /usr/src/linux symlink is bad; I have heard people freak out if the entire kernel-source tree is unpacked in a /usr/src/linux directory ... So far, everyone agrees that a /usr/src/linux symlink is ok, especially if some module depends on its presence. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpEoz4d3xXba.pgp Description: PGP signature
Re: New course for Debian University
Rob VanFleet wrote: > > Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, > AFAIK, is not the issue. The module I tried to compiled looked for the > kernel-includes in /usr/src/linux/include. I'm just wondering why > /usr/src/linux is bad, and how to tell compiles to look somewhere other than > /usr/src/linux. I read this just the other day (don't recall where; prolly on kt.linuxcare.com). Making a symlink in /usr/include is BAD because compiling apps against kernel headers different from the kernel headers glibc was compiled against is BAD. Making a symlink from /usr/src/linux-version to /usr/src/linux is NOT bad; I have never done this any other way. -- -=|JP|=-"Why, oh, why didn't I take the blue pill?" Jon Pennington| Atipa Linux Solutions -o) [EMAIL PROTECTED] | http://www.atipa.com/\\ Kansas City, MO, USA | 816-595-3000 x1550 _\_V 6D04 39E0 CAE9 9ADA 2CA3 2EBE 898A 6C37 CA1E A29C
Re: New course for Debian University
On Thu, Dec 28, 2000 at 04:54:54PM -0600, Nathan E Norman wrote: > On Thu, Dec 28, 2000 at 04:30:07PM -0600, Rob VanFleet wrote: > > On Thu, Dec 28, 2000 at 07:29:12PM +0100, Carel Fellinger wrote: > > > I think it would be wise (and more debian like:) to explain how to > > > compile the kernel as *non* root using fakeroot. Furthermore I seem > > > to recall discussions on this list that it's better to refrain from > > > using/creating that /usr/src/linux link. > > > > I've been reading that as well, but I have yet to find out why it is a bad > > idea. Also, when my system was originally installed I didn't have > > /usr/src/linux symlink, but until I made one I couldn't compile any modules. > > So how would one tell code that needs to look for the kernel headers to look > > somewhere else? > > I think there's confusion between making links in /usr/include and > links in /usr/src. The first is bad [0], the second is (afaik) not. Hmm, as I understood it, making a /usr/src/linux link is bad, /usr/include, AFAIK, is not the issue. The module I tried to compiled looked for the kernel-includes in /usr/src/linux/include. I'm just wondering why /usr/src/linux is bad, and how to tell compiles to look somewhere other than /usr/src/linux. -Rob
Re: New course for Debian University
On Thu, Dec 28, 2000 at 04:30:07PM -0600, Rob VanFleet wrote: > On Thu, Dec 28, 2000 at 07:29:12PM +0100, Carel Fellinger wrote: > > I think it would be wise (and more debian like:) to explain how to > > compile the kernel as *non* root using fakeroot. Furthermore I seem > > to recall discussions on this list that it's better to refrain from > > using/creating that /usr/src/linux link. > > I've been reading that as well, but I have yet to find out why it is a bad > idea. Also, when my system was originally installed I didn't have > /usr/src/linux symlink, but until I made one I couldn't compile any modules. > So how would one tell code that needs to look for the kernel headers to look > somewhere else? I think there's confusion between making links in /usr/include and links in /usr/src. The first is bad [0], the second is (afaik) not. HTH, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton [0] /usr/share/doc/kernel-package/README.headers pgpFdxwcJsFKN.pgp Description: PGP signature
Re: New course for Debian University
On Thu, Dec 28, 2000 at 07:29:12PM +0100, Carel Fellinger wrote: > I think it would be wise (and more debian like:) to explain how to > compile the kernel as *non* root using fakeroot. Furthermore I seem > to recall discussions on this list that it's better to refrain from > using/creating that /usr/src/linux link. I've been reading that as well, but I have yet to find out why it is a bad idea. Also, when my system was originally installed I didn't have /usr/src/linux symlink, but until I made one I couldn't compile any modules. So how would one tell code that needs to look for the kernel headers to look somewhere else? -Rob
Re: New course for Debian University
On Wed, Dec 27, 2000 at 08:12:05PM -0600, David A. Rogers wrote: > Kernel 150 - Compiling the kernel - is open for enrollment (The Debian > University document has been updated to include information on compiling the > kernel in the Debian way). > > Debian University can be found at: > > http://home.xnet.com/~darogers/debian_university.txt Nice initiative. > make-kpkg is very nice and makes compiling the kernel as easy as it can get I think it would be wise (and more debian like:) to explain how to compile the kernel as *non* root using fakeroot. Furthermore I seem to recall discussions on this list that it's better to refrain from using/creating that /usr/src/linux link. -- groetjes, carel
New course for Debian University
Kernel 150 - Compiling the kernel - is open for enrollment (The Debian University document has been updated to include information on compiling the kernel in the Debian way). Debian University can be found at: http://home.xnet.com/~darogers/debian_university.txt make-kpkg is very nice and makes compiling the kernel as easy as it can get (IMO). Comments are welcome. dar
