env-update uses python so dies without the symlink. The paths are hard coded in the binary according to ldd, so the environment isnt the problem. I think I need a minimum of correctly linked binaries to kick off a system rebuild.
BillK
From your ldd output, I don't see why your /usr/bin/python should use hard coded paths; when I run ldd /usr/bin/python, I get:
linux-gate.so.1 => (0xffffe000)
libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x4002f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40145000)
libdl.so.2 => /lib/libdl.so.2 (0x40196000)
libutil.so.1 => /lib/libutil.so.1 (0x40199000)
libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5 (0x4019c000)
libm.so.6 => /lib/libm.so.6 (0x40255000)
libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcc_s.so.1 (0x40277000)
libc.so.6 => /lib/libc.so.6 (0x40280000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
That doesn't look so different from your ldd's output, except for linux-gate.so.1, which is required by libgcc_s.so.1, the relocation
addresses (I guess? ldd's docs don't mention this) and that your libgcc_s.so.1 resolves to the old gcc's path (and this is the only
important difference).
Maybe you can check whether there actually is a /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcc_s.so.1 on your system. If so,
the old gcc dir seems to have preference over the new one. You can correct this by editing the LDPATH variable
in /etc/env.d/05gcc and running env-update. env-update should work if you run it with
'LD_LIBRARY_PATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2" env-update', since this variable takes precedence over
/etc/ld.so.conf. Then do an ldconfig and things should work.
-- [EMAIL PROTECTED] mailing list
