glibc recovery problems
I don't know how much you have been following the various threads related
to the __restore_frame_info problems with the 2.0.7u glibc, but it effects
dpkg in a critical way.
Programs compiled against 2.0.7u (1-5) will not run on either earlier, or
later versions of glibc. This was caused by a flaw in the u release which
exported the __restore_frame_info symbol to several inappropriate
libraries, including libm. The result is that, instead of the compiler
satisfying this symbol as it was expected to do, the symbol was left to be
resolved by libm at runtime. When that brokenness is fixed these programs
have nowhere to get this symbol resolved and can't run because of this
unresolved error.
It appears that at least one version of dpkg and apt were compiled against
the "u" glibc. It has been hoped that the resolution to this would be
for the new libc6 package to conflict with these versions of dpkg.
If only one release of dpkg is involved, I have no problem constructing
the "Conflicts:" field. If it covers a range of version numbers, it is
less clear to me how to construct the expression. Is any boolean
expression parsable? That is, how do I define a range of versions?
Can you tell me which versions were compiled against 2.0.7u?
There also appears to be some problems with libstdc++, but I will leave
that up to dpkg to deal with as that is its dependence. Once I release the
fixed 2.0.7u glibc, someone may have to rebuild libstdc++ against the new
library in order for the dpkg compiled against the fixed glibc will work.
This is not certain, but in any case must be left up to dpkg to deliver
the correct dependencies.
Your help bringing this issue to closure will be greatly appreciated.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: