Re: Bug#2697: symlink /usr/include/asm in libc5-dev
On Wed, 17 Apr 1996, David Engel wrote:
> > Sorry about not letting this die out, but I have been thinking
> > about this issue since my last message. You say that you are going to
> > include both /usr/include/asm-i386 and /usr/include/linux in
> > libc5-dev now. (aside: which kernel do these come from?)
>
> The are currently from 1.3.64, which is the latest includes package
> that I have.
>
> > I guess the pro is that everybody's development environment
> > (wrt.headers, at least) is locked in, and one may be able to
> > predict/reproduce compilations since all header files are the same.
>
> Exactly. This issue comes up on the linux-gcc list every so often.
> As usual, there was no resolution when it came up a couple of weeks
> ago, but there was considerably more support for doing it this time
> around. So much so that H.J. Lu said he would probably do it when he
> gets more disk space later this year.
>
> When libc 5.2.18 was recently broken by changes in the ~1.3.62 kernel
> headers and again (albeit temporarily) in ~1.3.81, I decided to go
> ahead and include "approved" headers with libc for Debian regardless
> of what H.J. Lu does. It will remain this way as long as I'm
> maintaining libc, which I hope is still on an interim basis.
>
> > But then, if ever there is a new kernel (either a new debian
> > package, or something that the user picks up herself) which has an
> > improvement/modification of the kernel headers, then one can't use it
> > unless one blows away the two directories from libc5-dev, and
> > installs two new symlinks. Unless, of course, the libc-dev package is
> > synched with the kernel packages (bletch!).
>
> First, the libc5-dev package will be updated periodically to recent
> kernel headers. Not counting bug fixes, this will probably be done at
> least once before the real release of Debian 1.1.
>
> Second, in my experience, very few programs actually need the very
> latest kernel headers. For those that do, you can just use the
> appropriate -I/usr/src/linux-X.Y.Z/include in your CFLAGS.
Except for the latest kernel, of course!
>
> > The fact that it may be a newly uploaded kernel sources debian
> > package means that hacking away in /usr/include should not be
> > required (I mean, if you get your own kernel, maybe we could say you
> > are on your own, but a bona-fide debian user upgrading packages
> > should not have to hack in /usr/include).
>
> 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)
Thanks,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software Fax: NONE
Black Creek Critters e-mail: dwarf@polaris.net
------------ If you don't see what you want, just ask --------------
Reply to: