Ken Moffat wrote:
>On Mon, May 29, 2006 at 03:41:20PM -0500, Arnie Stender wrote:
>
>
>>Hello,
>> I am working from "Cross-Compiled Linux From Scratch - Version
>>SVN-20060516-x86_64-Pure64". I am building for a roll your own
>>workstation with an Asus A8N32-SLI DELUXE motherboard with a single
>>AMD64 Athlon X2 4800+ CPU with 4Gig of memory. I was running into
>>problems and talked with Joe on the IRC channel and he asked me to
>>document issues I ran into while doing the build and Jim said put them
>>here.
>>
>> I got past the original problems I was having and am in section 10
>>doing the final build. I have compiled the glibc and am trying to get
>>through the make check. The current issue I am having is in the rt
>>directory. I get the following while it is doint the tst-timer.
>>
>>|GCONV_PATH=/usr/src/glibc-build/iconvdata LC_ALL=C
>>/usr/src/glibc-build/elf/ld-linux-x86-64.so.2 --library-path
>>/usr/src/glibc-build:/usr/src/glibc-build/math:/usr/src/glibc-build/elf:/usr/src/glibc-build/dlfcn:/usr/src/glibc-build/nss:/usr/src/glibc-build/nis:/usr/src/glibc-build/rt:/usr/src/glibc-build/resolv:/usr/src/glibc-build/crypt:/usr/src/glibc-build/nptl
>> /usr/src/glibc-build/rt/tst-timer > /usr/src/glibc-build/rt/tst-timer.out
>>/bin/sh: line 1: 2615 Segmentation fault
>>GCONV_PATH=/usr/src/glibc-build/iconvdata LC_ALL=C
>>/usr/src/glibc-build/elf/ld-linux-x86-64.so.2 --library-path
>>/usr/src/glibc-build:/usr/src/glibc-build/math:/usr/src/glibc-build/elf:/usr/src/glibc-build/dlfcn:/usr/src/glibc-build/nss:/usr/src/glibc-build/nis:/usr/src/glibc-build/rt:/usr/src/glibc-build/resolv:/usr/src/glibc-build/crypt:/usr/src/glibc-build/nptl
>> /usr/src/glibc-build/rt/tst-timer >/usr/src/glibc-build/rt/tst-timer.out
>>make[2]: *** [/usr/src/glibc-build/rt/tst-timer.out] Error 139
>>make[2]: Leaving directory `/usr/src/glibc-2.4/rt'
>>make[1]: *** [rt/tests] Error 2
>>make[1]: Leaving directory `/usr/src/glibc-2.4'
>>make: *** [check] Error 2
>>
>>Any help will be greatly appreciated. Thanks in advance.
>>Arnie
>>
>>
>
> I've no idea, and I haven't built pure64 for a month, which was
>with binutils-2.16.1 (and gcc-4.1.0) so there is a (slim) chance that
>something in the newer binutils needs adapting for this architecture.
>But first, some questions -
>
>1. On the line before this in your logs, when it compiled tst-timer,
>do you have -dynamic-linker=/lib/ld-linux-x86-64.so.2 ?
>
>2. Do you have a binary nvidia driver loaded ?
>
>3. Are you running an SMP kernel ? (I've never had an SMP box, and
>I'm not sure if everything can or cannot be built reliably on SMP,
>I'm just casting around for what might be different.)
>
>4. I don't know what your original problems were - is it possible
>that this segfault is a consequence of them ?
>
>Ken
>
>
Hi Ken,
1) I don't know it is scrolled out of my buffer.
2) a binary driver for what? The motherboard is built on the nvivia
chipset and the host OS is FC5 running on the target system. Other than
the SATA drivers I had to force load everything else that is loaded went
in automatically during the install of FC5.
3) FC5 installed 2.6.15-1.2054_FC5 #1 SMP
4) The whole test phase for glibc was "flaky". The make of the
package went through as far as I know without errors or at least none
that killed the make. When I did the make check it quit as some point. I
don't remember exactly where. I restarted it and it died again at the
same spot. I started asking questions on the IRC channel and people
asked some back and while trying to duplicate the problem the make check
ran through the point of the last die and died at a later point. I
started it again and it ran farther. Again the same thing and it ran
farther. After I made the post I blew away the build directory and
recreated it and picked up in the book from that point. Again the make
did not error out. The amke check ran to the point of the error that I
posted. I restarted it and it ran to completion with nor further
problems. I continued in the book and completed the installation of
binutils with as far as I can tell no problems. I don't like "flaky" but
as long as the only thing that is flaky is the test suite then I don't
care. At this point I am going to continue building my system. I will
watch for "flaky" behavior with the system as I build it but if the only
thing that doesn't work is the testing. I'll keep pressing on and see
how the system looks after it's finished. As long as the final system is
stable I'll be happy. Unless you really love pain I am willing to drop
this one unless I reach a point where the system itself turns unstable.
Thanks for your input. I'll post the outcome unless something else comes up.
Arnie
_______________________________________________
Clfs-support mailing list
[email protected]
http://ninja.linux-phreak.biz/mailman/listinfo/clfs-support