On Sun, Nov 01, 2015 at 04:10:52PM -0500, Michael Havens wrote: > Good afternoon. I am on section 5.33 . > Here is what I enter into the computer: > > #scp [email protected]:/home/bmike1/Documents/LFS/7.8/build/5.33build.txt > $LFS/sources;exit > #chmod 777 $LFS/sources/5.33build.txt; chown lfs > $LFS/sources/5.33build.txt;su - lfs
I've no idea whether this is relevant to your problem or not, but why are you su'ing to lfs for each package [ if I have interpreted you correctly ] ? We recommend building without scripts (and then booting, and going back and fixing the kernel .config until it *does* successfully boot) for the first build so that you can concentrate on what is in the book without worrying about the ways in which your own script can fail. On your first attempt last year, your machine died (been there in a different context, so you have my sympathies) so this is still your first build. And so, you become the lfs user, build some packages, perhaps log off and shut down, and later return, become the lfs user again, and build some more packages. Or, you leave the machine running but idle (not tremendously clever if the machine is using a lot of power, but it's how some of us started here). Or you build a bit and then let the machine sleep (if your machine is set up for suspend to RAM or even suspend to disk). We cannot guess at your background : some lfs builders seem to do it as a required stage before working as a developer, and they therefore start with a lot of knowledge (in particular, I remember one guy who worked for an obscure manufacturer who, when I said I was trying to build LFS on the product said "been there, done that."). We do not usually hear from those people because for them everything in LFS just works. You appear to not have much experience of building software, and therefore you have a lot to learn. That in itself is fine, but you are making the process harder for yourself by trying to automate some of the build before you understand what is going on. After a *successful* build, developing your own scripts is good, and worthwhile if you either want to stick with LFS and BLFS, or if you wish to develop your scripting skills. But until you have done it once, scripts are likely to get in your way. But anyway: > #cd $sources;./5.33build.txt > tar xf util-linux-2.27.tar.xz;cd util-linux-2.27 > ./configure --prefix=/tools \ > --without-python \ > --disable-makeinstall-chown \ > --without-systemdsystemunitdir \ > PKG_CONFIG="" > ( make 2>&1 | tee ../5.33.make.log && exit $PIPESTATUS ) && echo GOOD > #make check > ( make install 2>&1 | tee ../5.33.makeinstall.log && exit $PIPESTATUS ) && > echo GOOD > #rm -rf util-linux-2.27 > > The lines with the hash mark are entered individually (except for make > check. I do not enter that at all). > The error I am getting in the makelog is: > > collect2: error: ld returned 1 exit status > make[2]: *** [mount] Error 1 > make[2]: Leaving directory `/mnt/lfs/sources/util-linux-2.27' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/mnt/lfs/sources/util-linux-2.27' > make: *** [all] Error 2 > > the complete makelog is found: > > http://pastebin.com/GFtFP9Ng > If you cannot read your own log (NB having a log is *good*) and produce the error message associated with the error [ hint: it is almost certainly in the few lines above the collect2 error you showed ] then I'm not going to look at pastebin. If you find the detailed error message, then either you will be able to see what went wrong, or else you will still need to ask for help, but you will save the list from wasting time reading a log. > The makeinstall log error is similar: > Duh ? If *any* step in LFS fails, *STOP*. Attempting to install a package where the build has failed will normally begin by attempting to complete the build, and we know that will fail. In case it is not obvious (and apparently, it isn't), configure produces a Makefile (or a series of Makefiles in the top directory and some subdirectories) which ought to build on the current system with any options you specified. 'make' then builds the various targets (programs, libraries, documentation, whatever). 'make install' then attempts to install the targets - if they do not exist (in this case, because the build failed), it will try to build them so that it can install them. And, as before, repeating the same instructions after a failure is unlikely to work [ occasionally, it does - either there is a race in the Makefile and make -jN tries to build something before its dependencies have been created, or the machine is flakey - e.g. at least some AMD phenoms, one of which is mine : in those cases, a fallback of 'make' instead of 'make -jN' usually works ]. ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song" -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
