error when installing glibc(builds o.k.)

[Nix]

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!

>>> 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?

>> 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).

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!

>                                   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.