Ken Moffat wrote:
On Mon, 19 Sep 2005, Albert wrote:
LFS 6.1; chpt 6.13.1 Installation of Binutils; GoboLinux 012;
Here is the output from 'make check'. I can make no sense of it.
Any pointers appreciated.
I'm just catching up with my mail after a weekend away, but I think
I've seen several posts from you, and two things stick in my mind -
First, GoboLinux is probably one of the most unusual host distros you
can pick, which might mean it can generate difficulties of its own.
Yes, it wasn't my first choice. I have LFS 5.0 on another
partition, but I read somewhere that the host should have at
least kernel 2.6, and Gobo was the only one here that did.
Second, you've not specified what processor you are running on.
Intel Celeron I think. Whatever comes standard in a Dell
Dimension 2400.
root:/sources/binutils-build# make check
make[1]: Entering directory `/sources/binutils-build/bfd'
Making check in doc
make[2]: Entering directory `/sources/binutils-build/bfd/doc'
make[2]: Nothing to be done for `check'.
[ snipping the rest of this intro, I like a full log as much as the next
guy, but all this is absolutely normal stuff ]
Good to know.
WARNING: Couldn't find the global config file.
WARNING: Couldn't find tool init file
[ pretty normal so far ]
Those are the two messages that worried me most. I had no idea
what those files are.
Test Run By root on Mon Sep 19 17:24:34 2005
Native configuration is i686-pc-linux-gnu
=== binutils tests ===
Schedule of variations:
unix
Running target unix
Using /tools/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /tools/share/dejagnu/config/unix.exp as generic interface file
for target.
Using
/sources/binutils-2.15.94.0.2.2/binutils/testsuite/config/default.exp
as tool-and-target-specific interface file.
file isfile ../gas/as-new: 1
Running
/sources/binutils-2.15.94.0.2.2/binutils/testsuite/binutils-all/ar.exp
...
FAIL: ar long file names
ERROR:
This failure might be a platform-specific failure, I've seen it
somewhere (x86_64 or ppc, probably)
GoboLinux has doctored the kernel also, primarily to hide the
"legacy tree"(the standard FHS) from common utilities, like ls.
/sources/binutils-2.15.94.0.2.2/binutils/testsuite/binutils-all/bintest.s:
assembly failed
ERROR:
/sources/binutils-2.15.94.0.2.2/binutils/testsuite/binutils-all/bintest.s:
assembly failed
Looks like something is seriously broken, assembly isn't supposed to
fail. A week ago I had a nightmare build where for some reason the
mounting didn't all work (it's scripted, and the failure to mount was
not reproducible). Possibly you have somewhat similar weirdness.
=== binutils Summary ===
# of expected passes 1
# of unexpected failures 1
That will be ar long file names - bad if this is i686
Yep. It's a i686.
# of unresolved testcases 4
Those will be the assembly failures.
Something seems to be seriously wrong. For starters, check that /proc
and /sys are mounted (from inside chroot, a simple 'ls' will prove if
there is anything in these two directories).
root:/sources/binutils-build# ls /proc
1 187 2696 2846 2938 3026 6321 bus driver
irq mounts swaps
1033 188 2697 2847 2980 3027 786 cmdline
execdomains kallsyms mtrr sys
18 189 2698 2851 3 3028 84 config.gz fb
kcore net sysvipc
181 190 2699 2892 3015 3029 9 cpuinfo
filesystems kmsg partitions tty
182 2 2700 2927 3016 3046 909 crypto fs
loadavg pci uptime
183 2542 2775 2928 3017 4 954 devices ide
locks scsi version
184 2543 2787 2929 3019 5862 97 diskstats
interrupts meminfo self vmstat
185 2628 2788 2931 3023 5865 acpi dma iomem
misc slabinfo
186 2695 2841 2933 3025 6320 buddyinfo dri ioports
modules stat
root:/sources/binutils-build# ls /sys
block bus class devices firmware kernel module power
Also check for all the
device files from section 6.8.2.
root:/sources/binutils-build# ls /dev
console core fd null ptmx pts random shm stderr stdin
stdout tty urandom zero
Did you run the check for glibc without problems ?
One problem. I posted it at 09/18/2005 08:45 as "Re: make check
in 6.1/6.11" After seeing what it was, I assumed (erroneously?)
that it was harmless to me.
Have you come back to the build after shutting down ?
Several times. I run the following list of commands every time I
reboot the host. This is an aggregation of 6.2, 6.3 and 6.8:
mount /dev/hda6 /Mount/hda6.lfs
export LFS=/Mount/hda6.lfs
mount -t proc proc $LFS/proc
mount -t sysfs sysfs $LFS/sys
mount -f -t tmpfs tmpfs $LFS/dev
mount -f -t tmpfs tmpfs $LFS/dev/shm
mount -f -t devpts -o gid=4,mode=620 devpts $LFS/dev/pts
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
mount -n -t tmpfs none /dev
mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
mknod -m 666 /dev/ptmx c 5 2
mknod -m 666 /dev/tty c 5 0
mknod -m 444 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
chown root:tty /dev/{console,ptmx,tty}
ln -s /proc/self/fd /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/kcore /dev/core
mkdir /dev/pts
mkdir /dev/shm
mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm
Thanks for the reply, Ken. The diagnoses doesn't sound good.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
