This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: error when installing glibc(builds o.k.)


On 09/18/2010 02:05 PM, Nix wrote:
On 18 Sep 2010, Justin P. Mattock stated:

On 09/18/2010 07:40 AM, Nix wrote:
On 3 Sep 2010, Justin Mattock outgrape:

I seem to be hitting something here(below) Ive built glibc with gcc 4.6.0
with glibc git two weeks ago without such an error, pulled this morning,
and am now hitting this is this reported at all or do I have something wrong

Does 'make check' work? You should always *always always* run 'make check' and make sure that you know why every failure is occurring and that it is not problematic for your use.

I have not had a look at this since after posting this, due to getting patches reviewed and ready for the kernel(non trivial, but somebody had to go through the kernel updating all the web addresses..)

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



Basically, without 'make check' it is easy to toast your system subtly without realising it. Building glibc requires the built ld.so and libc to sort of work (you get failures at the others/sunrpc stage otherwise), but things like threading are not exercised at all by the build process. It would be unfortunate if you installed a glibc and found that threading or readdir() or something else critical not exercised much by the build process was horribly broken. ('make check' doesn't eliminate that possibility, but it does make it less likely.)

make install_root=/tmp/glibc-install
cd /tmp/glibc-install/lib # or lib32, or lib64
mv * /lib

The system I have right now, is a clfs so the above was what I did for the initial build of glibc on the host, and then install_root=* glibc over to the new system.(the mv * /lib bit I have not tried).

Ah. That's the essential part. You can't just install into /lib: what happens if the installation fails halfway through? You lose, that's what. While as long as you have the disk space, the mv isn't likely to fail or exec() anything short of disk failure.

# then possibly point the dynamic loader symlink in /lib at the copy in /lib32
# or /lib64, using sln(1)

/sbin/ldconfig # possibly --format=new

# only then move or symlink all the rest

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

I had symbolic links...

build nss with all the symlinks, just the plain lib itself.(but even

Well, ldconfig rebuilds those links, doesn't it? If it builds them wrong, this indicates that something's wrong with the soname of those libraries (most unlikely).

after resolving that the error above still occurred).

Yes, that error has nothing to do with this.

alright..



i.e. *move* it atomically into place using some command that does not
exec() additional dynamically-linked processes during the move
process. Nothing else can possibly be reliable. 'make install' tries to
make this work, but because nobody tests it that way it has a habit of
rotting.

I've been following glibc git, for a while now, and this has really been the only issue.. prior too I did fry the system, when I didn't set a switch with the build --enable-kernel=2.6.0 but was easily resolved with a livecd..

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)
as for the crash and burn... from what I remember either it was the kernel number switch or it wasnt, either way once glibc install hit math* everything stopped from there...(then went back to clfs for the variables they use, and rebuilt from the livecd and everything was o.k.).


Justin P. Mattock


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]