So here's the first glibc 2.2 backwards compatiblity problem that's come up, according to HJ Lu.....
>RedHat 7.0 uses glibc 2.2. There are some subtle changes from glibc >2.1 to 2.2. One of them is errno. From the glibc manual: > > The initial value of `errno' at program startup is zero. Many > library functions are guaranteed to set it to certain nonzero > values when they encounter certain kinds of errors. These error > conditions are listed for each function. These functions do not > ^^^^^^^^^^^^^^^^^^^^^^ > change `errno' when they succeed; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >This is no longer true in glibc 2.2. `errno' can change after the >return from a glibc function, successful or not. Any applications >depending the old documented glibc behavior may fail with glibc 2.2. >So far, I have found elm is one of them: > >http://sources.redhat.com/ml/libc-hacker/2000-09/msg00134.html > >I don't like this change. My concern is although the glibc manual >shouldn't have said "These functions do not change `errno' when they >succeed;" in the first place, changing the application source code >may not be an option for every Linux user. Glibc has to provide the >backward compatibility on this. But most of glibc developers don't >share my view. What if anything should we say in the specification about this? If we decide to use glibc 2.2 as our base specification, I think we're going to need to start an appendix listing differences between glibc 2.1 and 2.2. I ***hope*** that there aren't too many of these compatibility land mines hiding in glibc 2.2. - Ted P.S. My other big concern is that RedHat apparently shipped a pre-release of 2.2 (i.e., 2.1.91). Given that Ulrich works for RedHat I hope that someone at RH got Ulrich to sign a contract in blood stating that there will be no compatibility problems introduced between 2.1.91 and 2.2. Otherwise, this has the potential for causing a really big mess.....
