On Mon, Dec 21, 2020 at 09:10:23PM +0000, Ken Moffat wrote: > On Wed, Dec 16, 2020 at 09:49:38AM +0100, Pierre Labastie wrote: > > On Wed, 2020-12-16 at 00:48 +0000, Ken Moffat wrote: > > For Config.in, *IF* I go ahead with this approach (I'm having doubts > since so much manual intervention is required to clean up unwanted > configuration, or to allow rebuilds) I think that I'll maybe just > copy Config.in at the start. Ideally I would try to build > everything in one go (should be feasible if I get a new machine, but > needs at least a 40GB filesystem). [...] > This is turning into a very masochistic form of enjoyment. I hope > to report my current changes to generated scripts later (quite a lot > are because I don't want to actually run some of these things if I > do boot the created system), but at the moment that is getting > further and further distant. > > Meanwhile, I'm hoping to prove if my current variation for mounting > shm on an LFS-style sysv build (i.e. one where /dev/shm is a symlink > to /run/shm) will work - first test will be rebuilding python3 (that > got puleld in by something), and if that succeeds then building > thunderbird. >
I've abandonned this, so I'll not be using jhalfs for build testing in the near future and will probably only build those packages I use or care about. The deal-breaker is python's multiprocessing on LFS sysv where the bootscripts make /dev/shm a symlink to /run/shm. Multiprocessing is needed by all mozilla packages, I've had it working in the past in chroot, and at first it was working with jhalfs in chroot (I built firefox and seamonkey). But my mounting looked "odd" so I've been trying to get a better/cleaner approach without any success. Note that the problem is not building in chroot per se, it is re-entering chroot after the new system has been booted to test that it does boot. A lot of my variations in playing with shm mounts have crashed firefox and falkon on the host system - that's ok, this system is for development, I can live with that and reboot to get them back. My current set of packages includes js78 (for some reason make decided it needed to be (re) built) and also includes python3 at a much later date. I'm suspicious that python3 (and python2 for seamonkey) needs to be built in a system where shm is working, but for the moment I have no proof one way or the other. Got as far as js78, it failed. Hacked the Makefile to rebuild python3 before js78 - tried variations of the mounting, got nowhere. I've now reverted to what is essentially the mounts I use in my own builds: mount | grep $LFS/dev/shm || mount -vt tmpfs shm $LFS/dev/shm mount | grep $LFS/run || mount --bind /run /mnt/lfs/run (and as I said before, that seems back to front) but it is no-longer working (js78 failed, rebuilt python3, js78 still failed. Giving up, and no-longer planning to get a build machine for this. In passing, I'll mention that Xi's objection to mounting /run in chroot (processes in chroot could reboot the system) is valid for using chroot to separate running processes, but seems unlikely to be a problem when chroot is only used for building a new system. Ave atque vale. ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
