[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33



On 13 Apr 1998, Manoj Srivastava wrote:

> George> Then I build another glibc and kernel_headers?
> 
> George> Ok, I can probably live with that. Am I correct in my
> George> understanding that this is the way Debian is doing it? That
> George> you use a stable version of headers over many versions and
> George> only change headers used to compile user programs possibly
> George> when you release new glibc versions?
> 
> 	You are correct. The only exception to this are device driver
>  developers, but they are assumed to have enough know how to use a new
>  set of kernel headers using CFLAGS or whatever.
> 
> 	manoj

Except this doesn't work with the rules script in the glibc source
package. The first thing it does is removes the symlink and points it back
to the kernel_headers directory.  If your whole purpose in rebuilding the
package is to make it with a new set of kernel headers, this just adds
another step and introduces another chance to make an error.

Maybe the build script could notice that the symlink is pointed to
something else and ask if that is what the builder intends before
continuing?

Now I have to wade through the build script, comment at least that part
out and look at the rest of it with a skeptical eye that something else
might break.  

Since I am converting this system to completely 2.1, I am fairly certain
that I want a 2.1 compiled glibc. Otherwise I can not be sure if any
errors that might occur under severe stress are due to the kernel that I
am testing or an obsolete glibc. The test system has reached a load
average of 30 without dying but I am having trouble with a few network
related daemons (inetd and cucipop) dying for no reason at random
intervals even when not in use.  The point is to try to eliminate
incompatability as a problem by first making a glibc and then recompiling
the daemons in a native 2.1 enviorment. If they continue to die, at
least this potential problem will have been ruled out.



George Bonser

If I had a catchy quip, it would be here.

http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.


--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: