[2737] in SIPB_Linux_Development
Re: RedHat 6.0 sysname
daemon@ATHENA.MIT.EDU (Bill Zumach)
Tue Jun 1 10:00:43 1999
To: Jeffrey Hutzelman <jhutz+@cmu.edu>
Cc: linux-dev@MIT.EDU, cg2v+@andrew.cmu.edu, allbery+@cmu.edu,
vitroth+@cs.cmu.edu
In-Reply-To: Your message of "Fri, 28 May 1999 19:31:41 -0400."
<206965674.927919901@AFSTEST-2.FAC.CS.CMU.EDU>
Date: Tue, 01 Jun 1999 10:00:07 -0400 (EDT)
From: Bill Zumach <zumach+@transarc.com>
Hi,
The reason we are retaining i386_linux22 for the Redhat 6.0 port is that
if binaries done for 2.0.x don't work under 2.1.x there's an application
coding bug somewhere, either in glibc or the application. It doesn't seem
right to change sysnames to keep bugs alive. At the end of this mail is some
mail from Ulrich Drepper on comp.os.linux.development.system (sometime in May).
I expect that incompatibilities only exist for libio and one or tow other
libraries. The GNU folks intend to come up with bug fixes for those problems.
This of course is not to suggest that you shouldn't use a separate sysname
if you feel that works best in your situation. And picking a common
one is certainly preferable. I'm merely explaining why we kept the same
sysname. Actually, I'd be curious to know what applications you find that
do break.
For AFS builders:
The next AFS 3.5 patch builds on RedHat 6.0. There were a few minor tweaks
to the include lists and a couple of places needed to test the minor version
number for glibc.
Bill
------------------------------------------------------------------------------
Here's a bit from the FAQ for glibc2.1 as found in the RH 6.0 dist:
2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc
2.1?
{AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
that have been linked against glibc 2.0 will continue to work.
If you compile your own binaries against glibc 2.1, you also need to
recompile some other libraries. The problem is that libio had to be
changed and therefore libraries that are based or depend on the libio
of glibc, e.g. ncurses or slang, need to be recompiled. If you
experience strange segmentation faults in your programs linked against
glibc 2.1, you might need to recompile your libraries.
Another problem is that older binaries that were linked statically against
glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of
libnss_files.so.2), so don't remove them. Also, the old glibc-2.0 compiled
static libraries (libfoo.a) which happen to depend on the older libio
behavior will be broken by the glibc 2.1 upgrade. We plan to produce a
compatibility library that people will be able to link in if they want
to compile a static library generated against glibc 2.0 into a program
on a glibc 2.1 system. You just add -lcompat and you should be fine.
The glibc-compat add-on will provide the libcompat.a library, the older
nss modules, and a few other files. Together, they should make it
possible to do development with old static libraries on a glibc 2.1
system. This add-on is still in development. You can get it from
ftp://alpha.gnu.org/gnu/glibc-compat-2.1.tar.gz
but please keep in mind that it is experimental.
----------------------------------------------------------------------------
And from Drepper regarding compatibilty:
"G. Sumner Hayes" <sjhalpar@yahoo.com> writes:
> Is this level of binary compatibility a goal of the glibc
> developers? If so, what should the Linux community be doing to help?
> If not, then there appears to be a real split between the glibc camp
> and the Linux camp; what's the best way to go about mending it?
I'll comment on all this once, so don't bother sending me any mail:
- we care about binary compatibility. Why else should we have implemented
symbol versioning? It wasn't anybody of those complaining.
- some parts of the system (esp low-level libraries) are too tightly coupled
to the C library to prevent them from failing. But this is no big problem
since only those libraries and not the programs using them have to be
recompiled.
- all binary incompatibilities which are not documented are unexpected. They
are not fixed because
a) nobody has reported them
b) nobody helped fixing them
We only have very limited resources to test the new versions and to fix
problems. The only people who are paid to do these jobs and so can spend
their day with it are the distribution makers. My systems are exclusively
used for development, what the hell do I know what a system used for, say,
web serving requires.
The only way to ensure that nothing breaks is
- participating in the testing; there are always a number of test releases
- report and preferably *fix* problems
Those who don't do anything have not the slightest right to complain. At
least not to the glibc developers. One might have a right to complain if
one pays for something and then it is the distribution makers problem. They
should have tested things (I know they do but they also have limitations).
- for the 2.1 release especially some programs had problems because they use
undocumented *internal* interfaces. We simply had not the technology to
prevent stupid people from using these functions and variables.
Now we have the technology (again, implemented by Eric Youngdale and me).
No internal interface is exported and to make things clear, the headers
are also cleaned up and should not mention any internal interface anymore.
But we can't undo the damage caused by programmers who didn't follow the
rules in the past. There are ways around this and at least SuSE will
implement the way I suggested. But this solution *cannot* be part of the
libc since it would again allow writing non-conforming programs.
- some programs are written unclean. E.g., programs using
fp = setmntent (...);
...
fclose (fp);
do crash now. If the program would have been written correctly by using
endmntent (fp);
instead of the `fclose' call everything would be nice and easy. It only
accidently worked in the past.
- I really think that with symbol versioning it is possible to write
compatible libraries. Maybe other libraries should adapt it.
- the libc development will not continue indefinitely. There is an end in
sight. I have a few more large changes on the list but after that glibc
will be feature-complete. Changes will be limited to bug fixes, new
functionality and in limited amount of new features. All should be very
well implementable with breaking binary incompatibility.
And one more thing: I constantly keep reading something about "glibc
folks" versus "Linux folks". This is completely bogus. Except for
the, nowadays, three guys working on Hurd all active developers are
using Linux. HJ Lu and I are using Linux longer than 99.9999% of all
Linux users. Our main development platform is Linux. So stop this
nonsense!
I have stated this a few times already but newsgroups repeat itself
since people are too lazy to look up the archives. Maybe somebody can
put the above in an newsgroup-FAQ or so.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
