Re: [lfs-support] LFS-BOOK-7.0 Section 5.9 binutils pass2 doubt
On 6/19/2012 12:09 PM, Emerson Yesupatham wrote:
Hi,
I am trying to build LFS. I am following LFS-BOOK-7.0.pdf.
Problem:
I am facing the following error while compiling Binutils-2.21.1a -
Pass 2, section 5.9.
*configure: error: cannot run C compiled programs.* Complete error
is attached in config.log file.
The command executed was:
CC=$LFS_TGT-gcc -B/tools/lib/ \
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
../binutils-2.21.1/configure --prefix=/tools \
--disable-nls --with-lib-path=/tools/lib
Other information:
In my host system, the following important check under Caution
mentioned in section 5.8 Adjusting tool chain, is working fine as
shown below:
**
lfs:/mnt/lfs/sources$ echo 'main(){}' dummy.c
lfs:/mnt/lfs/sources$ $LFS_TGT-gcc -B/tools/lib dummy.c
lfs:/mnt/lfs/sources$ readelf -l a.out | grep ': /tools'
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
*My host system violates one of the prerequisites mentioned in page XVi*
*Linux Kernel-2.6.25 *
(having been compiled with GCC-4.1.2 or greater)
The reason for the kernel version requirement is that we specify that
version when building glibc in Chapter 6 at
the recommendation of the developers. It is also required by udev.
If the host kernel is either earlier than 2.6.25, or it was not
compiled using a GCC-4.1.2 (or later) compiler, you
will need to replace the kernel with one adhering to the specifications.
Question: I tried to locate solution for this error in the lfs-support
archive but could not find the identical one. Could any one help me
out on this? I am blocked due to this error completely.
I belive the above prerequisite violation should not create problem at
this point i.e. binutils pass2.
Thanks,
Emerson
First, use an HTML copy so you can copy+paste easier. Second, run all
the possible upgrades your distro offers. If your kernel is out-of-date,
then you must not be updating anything. Or, if it's something similar to
Slackware or Arch Linux, get the fresh packages and recompile them. Then
try building from the beginning. You might have better luck then.
Elly
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] LFS-BOOK-7.0 Section 5.9 binutils pass2 doubt
On Tue, 19 Jun 2012 18:09:21 +0100 Emerson Yesupatham yemerson1...@gmail.com wrote: *My host system violates one of the prerequisites mentioned in page XVi* *Linux Kernel-2.6.25 * So what are you saying, that your kernel is older than 2.6.25? Glibc is configured with --enable-kernel=2.6.25 so if you try to use it (eg, when configuring the next package, Binutils) with an older kernel it won't work and you'll get an error message like the one you posted. The obvious solution is to get a newer kernel but you could also try configuring glibc with --enable-kernel=$(uname -r) but it may not work (I can't remember why). So upgrade your kernel before you start the book. Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] /etc/fstab
I'd appreciate it if somebody could please have a look at my /etc/fstab
file shown below and let me know if it's OK. I've searched this mailing
list's archives and an example /etc/fstab I found was a bit different to
mine. I also had a look at the /etc/fstab files on a Ubuntu and Debian
systems, but they weren't as detailed as mine.
In particular, I'd like to know whether it is my /boot partition or /
partition that has to be checked by fsck. Is it OK for /boot to be ext3,
or should I have made it ext2? Googling it suggests that it's probably
better for it to be ext2, but ext3 should do fine as well.
:; mount
...
/dev/sda5 on /mnt/lfs/boot type ext3 (rw)
/dev/sda6 on /mnt/lfs type ext3 (rw,commit=0,commit=0)
/dev/sda7 on /mnt/lfs/opt type ext3 (rw,commit=0,commit=0)
/dev/sda8 on /mnt/lfs/usr/src type ext3 (rw,commit=0,commit=0)
/dev/sda9 on /mnt/lfs/home type ext3 (rw,commit=0,commit=0)
/dev on /mnt/lfs/dev type none (rw,bind)
devpts on /mnt/lfs/dev/pts type devpts (rw)
shm on /run/shm type tmpfs (rw)
proc on /mnt/lfs/proc type proc (rw)
sysfs on /mnt/lfs/sys type sysfs (rw)
root@hostname:~# file -s /dev/sda[5-9] | awk '{ print $1,$8 }'
/dev/sda5: UUID=64b0a82e-4500-49c0-b426-e97562ed0585
/dev/sda6: UUID=a2f6cc54-c7d7-41e9-8e00-123da318f743
/dev/sda7: UUID=140b05f2-6ca5-4cc8-b45b-52e6e6d2e164
/dev/sda8: UUID=a6563b03-a212-47b0-b6cc-7f767768852d
/dev/sda9: UUID=0901943d-ab94-423a-accb-cd425d3d13c1
root:/# cat /etc/fstab
# Begin /etc/fstab
# file system mount point type options dump pass
UUID=64b0a82e-4500-49c0-b426-e97562ed0585 /boot ext3 defaults 0 2
UUID=a2f6cc54-c7d7-41e9-8e00-123da318f743 / ext3 defaults 0 1
UUID=140b05f2-6ca5-4cc8-b45b-52e6e6d2e164 /opt ext3 defaults 0 2
UUID=a6563b03-a212-47b0-b6cc-7f767768852d /usr/src ext3 defaults 0 2
UUID=0901943d-ab94-423a-accb-cd425d3d13c1 /home ext3 defaults 0 2
UUID=c0882b91-9df5-43f9-b5e3-d77d68b53a33 none swap sw 0 0
proc /proc proc nosuid,noexec,nodev 0 0
sysfs /sys sysfs nosuid,noexec,nodev 0 0
devpts /dev/pts devpts gid=4,mode=620 0 0
tmpfs /run tmpfs defaults 0 0
devtmpfs /dev devtmpfs mode=0755,nosuid 0 0
# End /etc/fstab
Thanks.
Alexander Kapshuk.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] /etc/fstab
On Tue, Jun 19, 2012 at 09:27:03PM +0300, Alexander Kapshuk wrote:
I'd appreciate it if somebody could please have a look at my /etc/fstab
file shown below and let me know if it's OK. I've searched this mailing
list's archives and an example /etc/fstab I found was a bit different to
mine. I also had a look at the /etc/fstab files on a Ubuntu and Debian
systems, but they weren't as detailed as mine.
In particular, I'd like to know whether it is my /boot partition or /
partition that has to be checked by fsck. Is it OK for /boot to be ext3,
or should I have made it ext2? Googling it suggests that it's probably
better for it to be ext2, but ext3 should do fine as well.
ext3 should be ok for /boot. fsck will be run on *all* the
filesystems in fstab which are automounted and in need of an fsck.
:; mount
...
/dev/sda5 on /mnt/lfs/boot type ext3 (rw)
/dev/sda6 on /mnt/lfs type ext3 (rw,commit=0,commit=0)
/dev/sda7 on /mnt/lfs/opt type ext3 (rw,commit=0,commit=0)
/dev/sda8 on /mnt/lfs/usr/src type ext3 (rw,commit=0,commit=0)
/dev/sda9 on /mnt/lfs/home type ext3 (rw,commit=0,commit=0)
/dev on /mnt/lfs/dev type none (rw,bind)
devpts on /mnt/lfs/dev/pts type devpts (rw)
shm on /run/shm type tmpfs (rw)
proc on /mnt/lfs/proc type proc (rw)
sysfs on /mnt/lfs/sys type sysfs (rw)
root@hostname:~# file -s /dev/sda[5-9] | awk '{ print $1,$8 }'
/dev/sda5: UUID=64b0a82e-4500-49c0-b426-e97562ed0585
/dev/sda6: UUID=a2f6cc54-c7d7-41e9-8e00-123da318f743
/dev/sda7: UUID=140b05f2-6ca5-4cc8-b45b-52e6e6d2e164
/dev/sda8: UUID=a6563b03-a212-47b0-b6cc-7f767768852d
/dev/sda9: UUID=0901943d-ab94-423a-accb-cd425d3d13c1
Thanks, I didn't know that file could do that!
root:/# cat /etc/fstab
# Begin /etc/fstab
# file system mount point type options dump pass
UUID=64b0a82e-4500-49c0-b426-e97562ed0585 /boot ext3 defaults 0 2
UUID=a2f6cc54-c7d7-41e9-8e00-123da318f743 / ext3 defaults 0 1
UUID=140b05f2-6ca5-4cc8-b45b-52e6e6d2e164 /opt ext3 defaults 0 2
UUID=a6563b03-a212-47b0-b6cc-7f767768852d /usr/src ext3 defaults 0 2
UUID=0901943d-ab94-423a-accb-cd425d3d13c1 /home ext3 defaults 0 2
UUID=c0882b91-9df5-43f9-b5e3-d77d68b53a33 none swap sw 0 0
Why not just use /dev/sda5 /boot ext3 ... and similarly for the
others ? I suppose that UUID will work once udev is running. For
the rootfs, the kernel will try to use whatever root= you passed on
the commandline from grub : here UUID will NOT work (we don't use an
initrd) - and what is shown in /etc/fstab for '/' is at best
documentation.
Dump values of '1' are, or at least used to be, conventional for
ext filesystems, but that probably doesn't make any real difference.
So, I *think* that your fstab will probably work.
I also think that /usr/src and /opt are wastes of filesystems :
Anything you build in /opt will be linked to the libraries in /lib
and therefore might break work when you build your next LFS
because the versions will probably change. At the moment, the only
thing in /opt on my current system is llvm -
ken@ac4tv ~ $ldd /opt/llvm/lib/libLLVM-3.1.so
linux-vdso.so.1 (0x74fff000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fb9be449000)
libffi.so.5 = /usr/lib/libffi.so.5 (0x7fb9be24)
libdl.so.2 = /lib/libdl.so.2 (0x7fb9be03c000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fb9bdd3b000)
libm.so.6 = /lib/libm.so.6 (0x7fb9bda3f000)
libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7fb9bd82a000)
libc.so.6 = /lib/libc.so.6 (0x7fb9bd46d000)
/lib64/ld-linux-x86-64.so.2 (0x7fb9bfbbc000)
libpthread, libdl, libm libc, and even ld-linux are the things
which might break with a newer glibc. OTOH, those people who update
glibc in-place can probably handle this. I also believe that if I'm
going to install a new system, I want the current versions of
everything - not a version from whenever I installed the current
system.
The case against /usr/src is different : you can build packages
anywhere that there is enough space - on recent disks I dedicate a
large space to /scratch (it doesn't get backed up) and build within
that. On my previous smaller disks I used to build in /home (ok,
for scripted installss I have built in /usr/src if there was room,
and still use /mnt/lfs/usr/src, but it doesn't require a separate
partition).
Many desktop packages use a lot of space, but there is usually no
good reason to keep the build director{y,ies} around after a package
is installed.
Since I'm off on my partitioning hobbyhorse, I'll mention that
people who intend to keep using LFS will want a second filesystem to
use as /mnt/lfs for their next build. For many people, '/' from
their original host system can be used for that. Other approaches
are possible, but life is hard enough for those of us who build from
source, no need to gratuitously make things harder for ourselves.
proc /proc proc nosuid,noexec,nodev 0 0
sysfs /sys sysfs
