On 05/03/2016 21:31, Bruce Dubbs wrote: > Ken Moffat wrote: >> On Fri, Mar 04, 2016 at 09:46:40PM -0600, Bruce Dubbs wrote: >>> Ken Moffat wrote: >>>> >>>> This time, I took a look at the Makefiles (in build/), but AFAICS >>>> only the toplevel Makefile defines install-libs, as >>>> install-libs-recursive, and I cannot find any other references to >>>> install-libs and therefore no explicit rule for the recursive >>>> variant - I guess that -recursive perhaps tells make to run >>>> install-libs in all the directories, but I cannot see any >>>> instructions for that in any of them, so I'm no wiser about what >>>> command is segfaulting. I'm obviously missing something. Anybody, >>>> please ? >>> >>> Have I sent you my mount-virt.sh, umount-virt.sh, and clean-mnt-lfs.sh >>> scripts? Are you using jhalfs or your own scripts? >>> >> I don't have them, and I'm using my own scripts whichs seem to work >> well from LFS hosts¹ >> >> At the moment I'm backing up one of my rc2 systems after rebuilding >> the victims of openssl-1.0.2g, and I've just run >> make --debug=iv DESTDIR=/scratch/ken/E2FSPROGS2 install-libs 2>&1 | >> tee libslog >> >> I am amazed at the amount of output, but after about 2000 lines the >> first part of the install seems to happen: >> >> No implicit rule found for '../../../lib/et/com_right.c'. >> File 'installdirs-elf-lib' does not exist. >> Target 'installdirs-elf-lib' is double-colon and has no >> prerequisites. >> Must remake target 'installdirs-elf-lib'. >> make[1]: Entering directory >> '/scratch/ken/e2fsprogs-1.42.12/build/lib/et' >> MKINSTALLDIRS /lib /usr/lib >> mkdir /scratch/ken/E2FSPROGS2 >> mkdir /scratch/ken/E2FSPROGS2/lib >> mkdir /scratch/ken/E2FSPROGS2/usr >> mkdir /scratch/ken/E2FSPROGS2/usr/lib >> Successfully remade target file 'installdirs-elf-lib'. >> Looking for an implicit rule for >> '../../../util/install-symlink.in'. >> >> Of course, /lib and /usr/lib already existed in chroot. >> >> and then about 400 lines later >> >> No implicit rule found for '../../../util/install-symlink.in'. >> Must remake target 'install'. >> INSTALL-ELF-LIB /lib/libcom_err.so.2.1 >> SYMLINK /lib/libcom_err.so.2 >> SYMLINK /usr/lib/libcom_err.so >> LDCONFIG >> Successfully remade target file 'install'. >> File 'install' does not exist. >> Looking for an implicit rule for >> '../../../lib/et/compile_et.sh.in'. >> >> etc >> >> Unfortunately, it looks like that part DID happen in the chroot. >> >> AFAICS, the next hunk of activity is >> >> Must remake target 'installdirs'. >> MKINSTALLDIRS /usr/lib /usr/include/et /usr/share/et /bin >> /usr/share/man/man1 /usr/share/man/man3 >> mkdir /scratch/ken/E2FSPROGS2/usr/include >> mkdir /scratch/ken/E2FSPROGS2/usr/include/et >> mkdir /scratch/ken/E2FSPROGS2/usr/share >> mkdir /scratch/ken/E2FSPROGS2/usr/share/et >> mkdir /scratch/ken/E2FSPROGS2/bin >> mkdir /scratch/ken/E2FSPROGS2/usr/share/man >> mkdir /scratch/ken/E2FSPROGS2/usr/share/man/man1 >> mkdir /scratch/ken/E2FSPROGS2/usr/share/man/man3 >> mkdir /scratch/ken/E2FSPROGS2/usr/lib/pkgconfig >> Successfully remade target file 'installdirs'. >> >> Of those directories, all except /usr/include/et and /usr/share/et >> should have already existed in chroot. >> And those two /et directories did NOT get created. >> >> [1.] Full disclosure - my logging fixes for grep-2.23 did not do the >> whole job, because I failed to notice that both callers piped the >> output through grep. My latest changes seem correct in completed >> systems, and in chroot for as far as I got, but I'm again getting >> some ls errors on screen in my intochroot scripts for passwd and >> groups although the final logs look acceptable. >> >> In chroot (I've mounted it at /mnt/lfs from an LFS system to take a >> look at the evidence) - >> >> MKINSTALLDIRS = $(top_builddir)/../config/mkinstalldirs >> which matches the build I am using for DESTDIR. >> >> And config/mkinstalldirs is just a script from 1993-9, and it invokes >> mkdir. >> >> For the moment, I am none the wiser - that definitely sounds like >> the sort of thing which selinux might have stopped, but I disabled >> selinux and rebooted for the second attempt. > > It would be interesting if you could try a jhalfs build to see it that also > has a problem at the same place. > > I could get a Fedora iso and try it in a gemu session. Do you want me to do > that? > > -- Bruce > > > I have a VM with Fedora 21. Is it expected to give the same issue?
If so, I can test build with jhalfs. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
