sm-grimoire AT lists.ibiblio.org
Subject: Discussion of Spells and Grimoire items
List archive
- From: Hamish Greig <hgreig AT bigpond.net.au>
- To: sm-grimoire AT lists.ibiblio.org
- Subject: [SM-Grimoire] glibc spell
- Date: Sun, 11 Jan 2004 23:54:59 +1100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks to dufflebunk and evraire, I have hopefully tracked down the last bug
(except for [1]) in the glibc spell.
Many of you will remember glibc has been problematic to upgrade since our
sorcerer beginnings.
I *think* I found a solution to this when I upgraded the glibc spell to build
nptl [2] . Unfortunately, on older systems with alien glibc libs lying
dormant in /lib and /usr/lib, part of this fix, the addition of ldconfig to
/var/lib/sorcery/protected caused a bug.
ldconfig actually scans /lib and /usr/lib and it recreates common symlinks to
libraries it recognises. It recognises these aliens and relinks them to the
standard library name causing a conflict from trying to use two glibc
versions at the same time. I have now added the -X switch to the ldconfig
call in glibc BUILD, which tells it to use existing links and not to relink.
I think this now fixes the last bug in this *rewrite* (except for [1]), but
would like some extra testers and checkers. So could any adventurous people
with 2.2.5 or 2.3.1 alien glibc libs in /lib or /usr/lib please cast glibc
from test grimoire to check this ?
Hamish the horrible meddler
ps any good ideas for [1] would be appreciated.
[1]
http://bugs.sourcemage.org/show_bug.cgi?id=5512
kinetix's bug related to module-less kernels not having /lib/modules/$(uname
- -r)/build for the ./configure and the headers copying to use
[2]
prepare_install saves all the old libs to $SOURCE_DIRECTORY/old.libraries,
it then runs ldconfig $SOURCE_DIRECTORY/old.libraries,
then in the case of glibc it then manually makes a symlink from
$SOURCE_DIRECTORY/old.libraries/ld-$version.so to /lib/ld-linux.so.2
(ld-linux.so.2 is also a protected file so doesn't get dispelled),
then it dispels the libs from their normal place. In glibc this caused
problems with the test at the end of make install, as it was testing the new
libs, but with the old libs preloaded. To avoid this the spell now manually
makes a set of links from the newly compiled libs in SOURCE_DIRECTROY.bld to
the regular location in /lib. It does this immediately after prepare_install
and then once all the links are made it runs ldconfig. Then it moves on to
run make install.
This *instantly* updates the libs the system is using, and solves the problem
of preloading old libs while testing the new ones. Unfortunately as
mentioned, any previous failure of glibc will have left aliens in /lib
and /usr/lib that this ldconfig call was trying to relink to the standard
library name. Now using ldconfig -X should fix this, hopefully some people
can test this. (my system got freshly installed in may last year, so I have
no glibc aliens to truly test this against)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAAUer8fSufZR6424RAksdAJwIOYNHIfJwu4aE7Ye6iNSkJ/3urgCffztu
MZmpqpU91ZfAJmOefRHpC/Q=
=8G38
-----END PGP SIGNATURE-----
-
[SM-Grimoire] glibc spell,
Hamish Greig, 01/11/2004
- <Possible follow-up(s)>
-
RE: [SM-Grimoire] glibc spell,
evraire, 01/11/2004
- RE: [SM-Grimoire] glibc spell, Paul, 01/11/2004
Archive powered by MHonArc 2.6.24.