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

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?

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

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


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