error when installing glibc(builds o.k.)

[Justin P. Mattock]

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