Never mind, I figured this out. The 115-libffi step's configure script was guessing my CPU architecture wrong! Later Python uses libffi and crashes with an invalid instruction. I'm running this on an old Intel G860 processor. I edited the following script:
/mnt/build_dir/jhalfs/lfs-commands/chapter06/115-libffi and changed the configure line to: ./configure --prefix=/usr --disable-static --with-gcc-arch=native Now I finally got past the crash in 117-Python. Maybe the book should mention this option in Chapter 6 for the libffi build? Don On Tue, Jun 12, 2018 at 2:02 PM, Don Cross <[email protected]> wrote: > On Tue, Jun 12, 2018 at 12:59 PM, Don Cross <[email protected]> wrote: > >> On Sun, Jun 10, 2018 at 10:20 PM, DJ Lucas <[email protected]> >> wrote: >> >>> On June 10, 2018 9:10:00 PM CDT, Don Cross <[email protected]> >>> wrote: >>> >Hello. I have manually completed two LFS builds before now (on amd64 >>> >and on >>> >Raspberry Pi, based on http://intestinate.com/pilfs/), just so you know >>> >I'm >>> >not a total noob! :) >>> > >>> >I'm trying ALFS for the first time. I'm trying to build LFS (System V) >>> >8.0 >>> >because that is the highest version that is described as being >>> >compatible >>> >with jhalfs-2.4, according to >>> >http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks >>> > >>> >The main problem is jhalfs can't download this file because it doesn't >>> >exist: >>> >http://www.linuxfromscratch.org/lfs/downloads/8.0/lfs-boots >>> cripts-20150222.tar.bz2 >>> > >>> >I think this URL is coming from >>> >http://www.linuxfromscratch.org/lfs/downloads/8.0/wget-list >>> >which I'm guessing ends up being used to generate my local file >>> >/mnt/build_dir/sources/urls.lst (?) >>> > >>> >When I use my browser to look at the directory >>> >http://www.linuxfromscratch.org/lfs/downloads/8.0 >>> >... I see lfs-bootscripts-20170626.tar.bz2 instead. But when I look in >>> >wget-list in that same directory, it specifies downloading >>> >http://www.linuxfromscratch.org/lfs/downloads/8.0/lfs-boots >>> cripts-20150222.tar.bz2. >>> >So I'm thinking that is a bug, but I'm not sure how to correct this >>> >problem >>> >in the jhalfs-2.4 build process. >>> > >>> >What should I do? Is there some way to hack the build process to use >>> >the >>> >20170626 version of the file, or do I need to find the 20150222 version >>> >from somewhere else? >>> > >>> >Incidentally, the following URL is giving me a 500 Internal Server >>> >Error. >>> >(Maybe a temporary outage?) >>> >http://www.multiprecision.org/mpc/download/mpc-1.0.3.tar.gz >>> > >>> >I found the following instead, and it hashes to the same md5 checksum: >>> >https://ftp.gnu.org/gnu/mpc/mpc-1.0.3.tar.gz >>> > >>> >I just threw that in my $SRC_ARCHIVE, so I'm not worried about this one >>> >so >>> >much. Just thought the maintainers would want to know. >>> > >>> >Thanks in advance for any help. LFS is an awesome educational >>> >resource! >>> >- Don >>> >>> Best to use SVN version of jhalfs and build 8.2 (or SVN book if you do >>> long term maintenance anyway rather than rebuild). >>> >>> --DJ >>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>> >>> >> Thanks DJ. I tried your first suggestion: SVN current trunk version of >> jhalfs and 8.2 version of the book. The build got a lot further this time, >> though I am hitting another problem in the step 117-Python-3.6.4. The last >> few lines of /mnt/build_dir/jhalfs/logs/117-Python-3.6.4 are: >> >> if test "xupgrade" != "xno" ; then \ >> case upgrade in \ >> upgrade) ensurepip="--upgrade" ;; \ >> install|*) ensurepip="" ;; \ >> esac; \ >> LD_LIBRARY_PATH=/sources/Python-3.6.4 ./python -E -m ensurepip \ >> $ensurepip --root=/ ; \ >> fi >> /bin/sh: line 7: 30618 Illegal instruction >> LD_LIBRARY_PATH=/sources/Python-3.6.4 ./python -E -m ensurepip >> $ensurepip --root=/ >> make[1]: *** [Makefile:1099: install] Error 132 >> make[1]: Leaving directory '/sources/Python-3.6.4' >> >> My interpretation of the error is that there is something wrong with the >> built python executable, causing a crash due to an "Illegal instruction" >> exception. I put the complete log file and my build configuration file >> in: >> >> http://cosinekitty.com/jhalfs/ >> >> My host system is Debian Stretch 9.4.0 running on amd64: >> >> don@monolith:/mnt/build_dir$ uname -a >> Linux monolith 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) >> x86_64 GNU/Linux >> >> When I look at the above log, it really looks like there was no problem >> building the python executable, and I'm not attempting to cross-compile, so >> I don't understand why there is an illegal instruction being executed. Any >> help would be most appreciated. Also please let me know if there is more >> diagnostic info I can provide. >> >> Thanks in advance... >> - Don >> >> > Sorry for the double-post; I should have included this the first time. > Additional information: the python executable looks suspiciously small. It > is only 39K: > > don@monolith:/mnt/build_dir/sources/Python-3.6.4$ ls -l python > -rwxr-xr-x 1 root root 39328 Jun 11 18:40 python > > don@monolith:/mnt/build_dir/sources/Python-3.6.4$ file python > python: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not > stripped > > For comparison, the Python 3.5 executable on another computer I have here > (installed from Debian Stretch stable package) is 4.6 MB: > > don@spearmint:~$ ls -l /usr/bin/python3.5 > -rwxr-xr-x 2 root root 4747120 Jan 19 2017 /usr/bin/python3.5 > > don@spearmint:~$ file /usr/bin/python3.5 > /usr/bin/python3.5: ELF 64-bit LSB shared object, x86-64, version 1 > (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for > GNU/Linux 2.6.32, BuildID[sha1]=dbfc2e1a3c58b6d241b3f9af7b2fb3a24b81b90e, > stripped > > Maybe this will help someone point me in the right direction to getting my > build working? > > Thanks again, > Don >
-- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
