Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ok, moving along with the build I've again gotten a make check failure: this time while installing GMP.
From the error log;
Code:
...
make[3]: *** [check-am] Error 2
make[3]: Target `check' not remade because of errors.
...
Since Automake isn't installed yet that's none to surprising, but in the other tests I'm
also seeing:
Code:
/tools/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object.
collect2: ld returned 1 exit status
make[4]: *** [t-bswap] Error 1
Anyone run into similar with HLFS or a standard LFS build?
Regards,
James Rasmussen
Last edited by Jerasmussen; 08-30-2015 at 10:56 AM.
Reason: Subject Accuracy
Distribution: XCP on Debian Wheezy; Raspbian; HLFS
Posts: 30
Original Poster
Rep:
Sure.
The host system for the HLFS build is Debian 3.2.68-1+deb7u2 i686, running PV on a Xen cloud platform . The Xen host system is Debian 3.2.68-1+deb7u2 x86_64. The version of Xen installed on the host is 4.1.4 with the xe command line interface.
I'm not sure what you mean by "output of the standard LFS book checks." I have stdout and stderr logs for the make check:
Runniing the test suite make -k ckeck reveals that the fatal error is due to [check - am]. I expected that would happen, since at this stage in the build automake isn't installed; I didn't expect all the warnings about creating a DT_TEXTREL in a shared object. It has to do with hardening, perhaps?
It's damned annoying in any case, as gcc just aborts the test & returns a non-fatal error; no insight into the actual functionality of the compiled code.
The DT_TEXTREL errors are apparently caused by busted PIC, " due to poorly written x86 assembly...."
Charming; I'm SO looking forward to debugging in HEX.
Anyway, the main focus of the guide is using PaX Utilities to track down and fix the problem code. As I see it I have two choices:
a) copy the PaX Utilities tarball to $HLFS/sources as root, then Chroot to the build environment and install it;
b) format the build partition, restore the toolchain from backup, add the needed utilities to the toolchain and redoo everything from there.
I don't want to loose all the work I've done installing User Package Management tools and building the OS up to this point. I'm also not sure I want these utilities taking up space in the OS when its finished. Then again, they might be useful for future source code installations. Opinions?
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
Did you check for all-or-nothing for the 3 libstc++ math libraries on the host system? i.e. Did you run library-check.sh after running version-check.sh? You should have all 3 or none at all.
Distribution: XCP on Debian Wheezy; Raspbian; HLFS
Posts: 30
Original Poster
Rep:
Hi Keith; Luridis; thanks for responding.
The version check script in the HLFS book provided the following result:
Code:
bash, version 4.2.37(1)-release
/bin/sh -> /bin/dash
Binutils: (GNU Binutils for Debian) 2.22
bison (GNU Bison) 2.5
/usr/bin/yacc -> /usr/bin/bison.yacc
bzip2, Version 1.0.6, 6-Sept-2010.
Coreutils: 8.13
diff (GNU diffutils) 3.2
find (GNU findutils) 4.4.2
GNU Awk 4.0.1
/usr/bin/awk -> /usr/bin/gawk
gcc (Debian 4.7.2-5) 4.7.2
version-check.sh: line 22: /lib/libc.so.6: No such file or directory
grep (GNU grep) 2.12
gzip 1.5
Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.68-1+deb7u2
m4 (GNU M4) 1.4.16
GNU Make 3.81
patch 2.6.1
Perl version='5.14.2';
GNU sed version 4.2.1
tar (GNU tar) 1.26
Texinfo: makeinfo (GNU texinfo) 4.13
Compilation OK
I didn't look at the LFS 7.7 version checks b/c I am building HLFS. I ran them just now, with the following results:
LFS_7.7_Version_Check
Code:
bash, version 4.2.37(1)-release
/bin/sh -> /bin/dash
Binutils: (GNU Binutils for Debian) 2.22
bison (GNU Bison) 2.5
/usr/bin/yacc -> /usr/bin/bison.yacc
bzip2, Version 1.0.6, 6-Sept-2010.
Coreutils: 8.13
diff (GNU diffutils) 3.2
find (GNU findutils) 4.4.2
GNU Awk 4.0.1
/usr/bin/awk -> /usr/bin/gawk
gcc (Debian 4.7.2-5) 4.7.2
g++ (Debian 4.7.2-5) 4.7.2
(Debian EGLIBC 2.13-38+deb7u8) 2.13
grep (GNU grep) 2.12
gzip 1.5
Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.68-1+deb7u2
m4 (GNU M4) 1.4.16
GNU Make 3.81
patch 2.6.1
Perl version='5.14.2';
GNU sed version 4.2.1
tar (GNU tar) 1.26
makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.1.0alpha
g++ compilation OK
LFS_7.7_Library_Check
Code:
libgmp.la: not found
libmpfr.la: not found
libmpc.la: not found
Interesting that the GMP, MPFR and MPC libs are missing from Debian, but I'm not sure how that's significant when I'm in a chroot environment, working off a toolchain with GCC-4.5.3 & all these libs installed. Then again, I'm new at this and probably couldn't find a clue with both hands and a flashlight.
Regards,
James Rasmussen
Last edited by Jerasmussen; 09-01-2015 at 11:43 AM.
Reason: Typos
Check your APT and see if you downloaded the correct g++ compiler. I'm a little fuzzy on what that line means. But I am going to assume that it's built to build against EGlibc instead of glibc.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
But, if I am completely honest about this...
I've built LFS systems from Debian in the past without issue. But, when I started 7.7 this last week, I first tried it from the latest Debian + LXDE. I also ran into compilation problems in Part III. There were some issues building diffutils and a few others. When I got to building Linux 3.19, it had too many errors to diagnose.
So, I started over from a Slackware 14.1 + xfce system, no issues there at all.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
One more thing... Are you building on a virtual machine of any kind? If so are you building from an i686 compiler host? If so does your PC have a 64 bit processor?
If all of those were yes... Did you put ABI=32 in front of your GMP ./configure line?
Distribution: XCP on Debian Wheezy; Raspbian; HLFS
Posts: 30
Original Poster
Rep:
I actually looked into EGLIBC prior to starting this build. It was a GNU libc implementation intended to be lightweight, for embedded Linux (hence the "E") and "strived to be source and binary compatible with GLIBC." I say was, because according to the home page it's been merged (re-merged?) with Glibc. Here's the link, if you want the sorted details... http://www.eglibc.org/home
Anyway, I ultimately used the same version of Glibc in the HLFS specs, good old Glibc-2.12.2; that's what's in the tool chain.
I am building on a virtual machine, the i686 version of Debian Wheezy. That machine is running on Debian Wheezy x86_64 via xen 4.1.4. The Hardware is a Gateway DX-433, which has an i5, 64-bit CPU. Four VCPU's are allocated to the x86_64 machine; 1 VCPU is allocated to the i686 machine on which the HLFS build lives. I've tried configuring GMP with ABI=32 set manually, as well as letting the linker figure it out. Both methods give me the same errors.
Although Dash is present on the host system, it is not present in the toolchain. As I understand from the book, the HLFS build environment is "clean" i.e, completely isolated from the code running on the host. The book spends a great deal of effort in fact, to ensure this. So I'm not sure how having Dash as the host machine's system shell makes a difference. Or are you saying the tool chain itself is corrupted, by virtue of having been built on a Debian host to begin with?
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
Quote:
Originally Posted by Jerasmussen
Or are you saying the tool chain itself is corrupted, by virtue of having been built on a Debian host to begin with?
I'm not saying anything with wrong with Debian's toolchain. I am saying that I ran into issues I couldn't fix with it and started over on Slackware and had no further problems. A piece of software doesn't have to be broken to create problems. All it needs is to have some unforeseen & hidden incompatibility with what you happen to be trying to do in order for it to become a problem.
I've given every piece of advise I know. If no one else comes along with the answer, then why not try a different platform? I was at the kernel build stage when things totally fell apart. I started over and was back to that point about 6 hours later.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
unless you make the host complient before building the tool chain you will run into loys of odd errors especially with gcc and glibc, once the tool chain has been made you can do what you want to the host, but first you need to build the roolchain correctly, until you have built lfs at least a couple of time please follow the book exactly that means using a complient host first.
Building on a VM also seems to cause problems, don'tmknow why as I've never done it, but a lot of people buliding on a VM report problems here.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
Quote:
Originally Posted by Keith Hedger
unless you make the host complient before building the tool chain you will run into loys of odd errors especially with gcc and glibc, once the tool chain has been made you can do what you want to the host, but first you need to build the roolchain correctly, until you have built lfs at least a couple of time please follow the book exactly that means using a complient host first.
Building on a VM also seems to cause problems, don'tmknow why as I've never done it, but a lot of people buliding on a VM report problems here.
I've built every version I've done on a VM without issues. For one thing, it is much, much faster. I think the biggest problem is people don't know how to config kernels for VMs.
For instance: Almost every device appears on a PCI or USB hub. Even devices that can't in the real world. Almost every peripheral-link device requires the USB 2.0 driver and USB HID driver. Then there's PAE, host BIOS settings, balloon drivers and all that comes before building the paravirtual modules after it's up and running on emulated hardware. Some people don't do the last step, but data transfer over emulated PCNet32 is not near as fast as VMWare's vmxnet paravirtual driver.
I'm about to start over on this build so I can switch to Linux 4.2. It seems the 3.15 and later kernels had some issues with unfixed vm driver bugs that appeared, I assume, because of internal kernel changes. Since I am not that far in, I might as well build glibc to the 4.2 headers while I am at it.
Edit: I've not tried this on a Xen host though. I use VMWare Workstation 10.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.