This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: error when installing glibc(builds o.k.)
On 09/19/2010 04:45 AM, Nix wrote:
On 18 Sep 2010, Justin P. Mattock told this:
On 09/18/2010 02:05 PM, Nix wrote:
Yeah, I noticed the patchbomb. You might want a *few* fewer patches next
time. :)
next if I ever find myself with loads of fixes, I think I'll have it at 10/15 per page..
Just agglomerate the patches by subsystem. It's not as if people *need*
the ability to reshuffle web address fixes into a different order!
alright..
I noticed so far with ldconfig -v was nss has wrong symlinks to the
it's libs, i.e. there is an NSS environment variable that does not
I have no idea what environment variable this might be that you're
referring to. Some LFS-specific thing?
taken from: https://developer.mozilla.org/en/NSS_reference/Building_and_installing_NSS/Build_instructions
NSDISTMODE: If set to 'copy', mozilla/dist/<OBJ_STUFF>/bin/* real files instead of symbolic links
Oh, this is NSS-the-crypto-engine, not NSS-the-Name-Service-Switch.
This is almost certainly the result of the soname being wrong: ldd sets
up symlinks from a library's soname to the library itself, so that the
dynamic linker can find them by soname.
I had symbolic links...
Yeah, but once you installed them they were real libraries, right?
You didn't have stuff in /usr/lib which was a symlink pointing into
a source tree?
yeah not the caching service, nss(and nspr) although I do have the
cachin service running, and all is good.. as for the symlink thing
from what I remember after building nss you just cp all the libs, *.h's
etc.. to the appropriate locations... (with the symlinks and all). keep
in mind I on the other hand wanted to build
xulrunner/firefox/thunderbird with as many system libs as possible so
having sqlite/nspr/nss set correctly was where I found out this whole
symlinks thing..
make check would have spotted that. (For that matter I'm not really sure
how such a glibc even built, unless you were building with a different
kernel than you then ran with, or cross-building or something like
that.)
I didnt do make check(I know..) I usually just make, sudo make install..
(vary bad habit on my part)
Quite so. I can't count the number of times (as another homebrew Linuxer
scorning distros) that a package's testsuite has alerted me to some bug
before installation. This is particularly critical if you're installing
things in /, or things which might break your build system terminally
(make, binutils, gcc, glibc, coreutils, sed, awk).
true... I just figured I would connect the dots once I got there, which
ended up happening, with latest make glibc craps out, zlib and libxml2
dont like each other..
As I see it the job of LFSers (if we have one) is to find (and hopefully
fix) obscure bugs in build systems and packages which are not tripped
over by the build systems of the big distros (generally, but not always,
obscure edge cases or performance oddities). There's no point killing
ourselves with bugs that other people have already encountered!
true... but it is nice when the maintainer is watching his code like a
hawk, and making sure everything is go to go...(as opposed to somebody
who just ignores all posts, and lets the code just site there broken..)
either way once glibc install hit
math* everything stopped from there...
Yes, running (and exec()ing new programs) with one libc and a different
libm is a recipe for unpleasant fun (though not as unpleasant as if libc
and ld-linux.so don't match). Just another reason to install /lib
atomically.
Id prefer to have glibc install itself.. really nice how that whole
mechanism copies and moves things around...
Justin P. Mattock