On Tue, May 29, 2001 at 07:51:04PM +0000, Richard Adams wrote:
> Anyway i cant see a (g)libc problem in the kernel souce from the
> discussion on this thread. Only if the libs are so outdated not to be
> compatable with the souce of today, however that is all explained in the
> Changes file, but what the heck, who reads the dam doco's anyway..
To quote one Linus Torvalds (perhaps you've heard of him):
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.
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..
The above can be found at:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0007.3/0587.html
> > There should be NO symlinks from /usr/include to
> > /usr/src/linux/include/(whatever).
>
> Ok, write to linux-kernel and tell then to alter all previous kernel versions
> before 2.4, Remember this, i have said it time and time again, differnt distro's
Well, Linus has been saying for _years_ that there should be no symlink from
/usr/include into the /usr/src/linux/include stuff. And since I don't
think 2.4 has been out for years, then I do believe that most kernels prior
to 2.4 have followed this strategy. Is it NOT anything new.
> do things differently, you can as a user alter what you want, i prefer the way
> "slackware" does it which is in tradition the linux way, it still does what i
> have told you and AFAIK will do so untill the masses do otheriwse or pressure
> to change avails. If i have my way i say leave it as is.
For libc5, it was necessary to have /usr/include/{asm,linux} point to the
latest kernel version in order to obtain new features as they were
developed.
But libc6 works differently. It _MUST_ have the contents of
/usr/include/{asm,linux} be exactly the kernel against which it was built.
You may get lucky and things will work correctly if you mix and match.
But, as the thread that Linus made the above comment pointed out, it does
still break. It's not worth the risk.
So, the new Linux tradition is, when you build a new libc, you copy the
contents from <linux>/include/asm into /usr/include/asm and
<linux>/include/linux into /usr/include/linux. Where <linux> is wherever
your linux kernel may lie. (In my case, for instance, it is
/usr/src/linux/linux-2.4.5.)
> So saying there should be NO symlinks in the linux directory is simply not
> true, there are and as i see it will be for a while to come, possably not in your
Yes it is.
> Redhat distro, but thats your thing, i presume you have Redhat considering your
> views.
Personally I don't use any distributions if I can help it. At work I use
debian and mandrake. Debian gets it right (no symlink), mandrake gets it
wrong. At least for the versions that I'm using. And I believe the debian
one is fairly old. They've been doing it right for a long time.
> No point, my points have been made, all i have done is show that many distro's
> still do it the linux traditional way.
If distributions would still using onlyt the "traditional" libc5 or libc4
libraries, would you be as tolerant of them? If they broke from those
traditions, they should break from the symlink tradition as well.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
