[gobolinux-users] trouble when compiling Glibc 2.8 on a fresh install
cj.karlsson at gmail.com
Mon Mar 2 09:27:24 NZDT 2009
2009/2/27 João Felipe Santos <joao.eel at gmail.com>:
> /bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
> open shared object file: No such file or directory
The loader can't find the libraries.
> and the build stopped. And then, zsh also was not working anymore,
> because of the same error (it is related to some ncurses library). I
> could do nothing then, but exited the chroot to look for system
> inconsistencies. Found that /Programs/Glibc/Current still pointed to
> 2.5, but /Programs/Glibc/Settings was pointing to the 2.8 Settings
> dir. I tried to fix it by hand but still cannot chroot or boot under
> my new system, because there's still the Ncurses error.
Not just Ncurses, but that is visible since it's one of the first
shared libraries a system tries to load.
> I don't know if this is a Compile bug, but this inconsistency under
> /Programs/Glibc was unexpected for me. Any ideas? If this is something
> that cannot be fixed, I don't have problems in reinstalling my system,
> but I still want to recompile my system to use Glibc 2.8 and GCC 4.3.
> How people usually do this under Gobo?
It's a sandbox bug, but I don't see why it haven't showed up earlier.
SandboxInstall moves Settings to Settings.hold when not using
UnionSandbox (and Glibc recipe disables sandbox altogether). This move
breaks Glibc, and the whole system, since the loader can't find
libraries when ld.so.cache isn't found.
The reason for the move is that write to Settings should be redirected
to Resources/Default/Settings, which is done by creating that symlink.
Problem is with first move breaking the system SandboxInstalll doesn't
have a change to create that symlink. The target of the symlink then
already holds a ld.so.cache. These two operations need to be one
operation, or at least the breaking/symlinking operation. Anyone have
More information about the gobolinux-users