Error when installing Binutils in chapter 6.13 (LFS v8.0)
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.
Error when installing Binutils in chapter 6.13 (LFS v8.0)
Hello,
I'm working my way through the LFS book and I've recently come across this error when trying to install Binutils with "make tooldir=/usr":
Code:
configure:2334: loading cache ./config.cache
configure:2371: error: `target_alias' has changed since the previous run:
configure:2379: former value: `x86_64-lfs-linux-gnu'
configure:2381: current value: `x86_64-pc-linux-gnu'
configure:2371: error: `LDFLAGS' has changed since the previous run:
configure:2379: former value: `-static-libstdc++ -static-libgcc '
configure:2381: current value: ` '
configure:2398: error: in `/sources/binutils-2.27/build/libiberty':
configure:2400: error: changes in the environment can compromise the build
configure:2402: error: run `make distclean' and/or `rm ./config.cache' and start over
.
I've tried the suggestion to to run
Code:
make distclean
and
Code:
rm ./config.cache
, but without avail. How can I fix this problem?
Here is a general list of info that may help you:
My OS is Peppermint OS 8.0 (based on Ubuntu 16.04.2)
I'm building this in a VM
I do have a dual core processor, but I didn't put the "-j2" tag on the "make"s
I have a 64 bit architecture, and the chapter 5 sanity tests also agree with it
It looks as if you are building in a source tree that you have used before. You never do that in LFS. Always delete the directory when you have finished with it. If you need to build the same package again, unpack the source tarball and create a new source tree for your build.
Thank you so much for helping me clear out this issue! I've been wondering about what to do with the previous "build" dir each time I'm told to run "mkdir build" again, and again, and again.
So, after I've finished using the "build" dir, I just "rm -rf build" and continue.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
Quote:
Originally Posted by Microbob
Thank you so much for helping me clear out this issue! I've been wondering about what to do with the previous "build" dir each time I'm told to run "mkdir build" again, and again, and again.
So, after I've finished using the "build" dir, I just "rm -rf build" and continue.
Thank you again!
I can tell you from experience that just scrubbing the build sub-directory may not be enough for some packages. If it doesn't work try removing the whole tree. As for doing things "again and again," you'll need to get accustom to doing so. BLFS has many more packages than the base system. Here are some things that might help with the typing:
export rr="./configure --prefix=/usr --disable-static" (or prefix=/tools where needed.)
Then you can type:
$rr && make && make check
Don't forget that you can also simply press the up-arrow to scroll back through your shell history and press enter to use the command again. Just don't forget to override or append the shell variable when there are extra configure flags.
It's best just to craft a build-script that can easily be recycled, similar to Slackware's SlackBuilds. I have actually crafted my own scripts using the SlackBuild style to enable usage of pkgtools and use them extensively with minor upgrades as needed for newer packages. Using these I also have dependencies mapped out, and have crafted a few crude pre-requisite checkers to ensure a dependency is installed before compile time.
I went back and restarted the book, but this time I "rm -rf build" each time I was done with the build dir. This time I got stopped at the first command in 6.10 "Adjusting the Toolchain". I couldn't
Code:
mv -v /tools/bin/{ld,ld-old}
because
Code:
mv: cannot stat '/tools/bin/ld': No such file or directory
. This also happened to the file "ld-new".
What went wrong? Everything before it went smoothly, and then I ran into this issue. What can I do to fix it?
Thanks!
P.S.: thanks for the build/make script idea, but I prefer to do each "make" command individually so I can see if there was an error when I run them.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
There is an order to things, during the course of the build, some things will change in /tools. (simlinks, files removed, etc.) That is why the instructions say to back up /tools after the strip at the end of chapter 5.
Basically, during the final binutils build of chapter 5, you compiled an extra linker, intended to be used after glibc was built but before the final build of binutils:
Code:
make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib
cp -v ld/ld-new /tools/bin
They had you do this then so you would have a linker pointed at the local filesystem immediately after building glibc in chapter 6. In the section "Adjusting the Toolchain" you swap it out for the one that was pointed at /tools/lib and create new simlinks with the target triple.
If you had read that black-on-white bit between the code blocks (commands) you'd understand what happened. I suggest going back and reading the book by itself, without following the instructions at the same time. This is not paint by numbers.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.