Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, Mar 27, 2020 at 08:26:39PM +0100, Pierre Labastie via blfs-dev wrote: > On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via > > blfs- dev wrote: > > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev > > > wrote: > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > > _exported_. It can be set to /bin/bash without problem. And > > > for me, it is not exported for _root_ after entering chroot > > > (but it is set): root [ / ]# echo $SHELL /bin/bash root [ > > > / ]# env | grep SHELL root [ / ]# Now when doing su - > > > pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ > > > env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need > > > to set/export anything as a user. And SHELL only needs to be > > > exported as root. Pierre > > > > > > > I'm puzzled by that - if it is not set, the configure breaks. > > Does SHELL also get queried when root is running the install ? > > > > > > When it is set, but not exported, it's not set in ./wmach, so not > found... So I'd just suggest something like: Second, you should > ensure that the SHELL variable is set and exported to the > environment, possibly by prepending SHELL= to the > .mach command. > > Pierre > I see you are moving away from saying /bin/sh which we have in the current firefox note. Are you using dash or zsh on the quiet ? (joke/). I can see we don't accomodate tcsh (setenv SHELL /bin/tcsh or similar) and certainly not fish (env SHELL=/usr/bin/fish command - I guess). Maybe: "Second, you should ensure that the SHELL environment variable is set to point to your shell and exported (e.g. for the common case using bash, export SHELL=/bin/sh) or alternatively prepend SHELL= when compiling." But my 'when compiling' can still be misinterpreted - although firefox and thunderbird use ./mach, seamonkey uses the old make -f client.mk and both versions of JS use ../js/src/configure. I picked the word compiling because we tend to say 'Compile by running the following command(s).' And I would really like to use a common xincludes for all the affected mozilla packages. Perhaps three versions (for mach, client.mk, js/configure) is the only way to be accurate. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On Sat, Mar 28, 2020 at 12:48:38AM +0100, Uwe Düffert via blfs-dev wrote: > Hi all, > > On Fri, 27 Mar 2020, Ken Moffat via blfs-dev wrote: > > > On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs-dev > > wrote: > > > > On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: > > > > Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error > > > It seems that using system LLVM is broken with rustc-1.39. > > For the *second* step, we need to think abou moving to rustc-1.42.0. > FYI: I built rustc-1.42 without issues about a week ago (with llvm-9.0.1) as > well as just now (with llvm-10.0 and no instruction changes). > > librsvg-2.48.0, gimp-2.10.18 and firefox-75.0b10 build and run fine with > that (llvm-10.0, rustc-1.42, ...) for me. > > Is there any special reason we would want to upgrade llvm but not rustc? > Both are rather ugly packages with pretty long pretty similar build times, > but recent rustc versions are available way longer than the recent llvm one. > I'd even expect rustc to be easier to upgrade due to fewer stuff to test!? > > Uwe Hi Uwe, for 'fewer stuff to test' I don't think very much has yet been tested with llvm-10.0, other than rustc-1.39.0 which was found wanting ;-) I'm glad to hear that librsvg and ff75.0b10 build with 1.42.0. But 1.42.0 needs to be built and measured, and the packages using rust build-tested. Seamonkey will definitely need patching. Meanwhile, I've now got the measurements for 1.39.0, and I was surprised to notice that one more test passed instead of being ignored. I'll create tickets, and then update rustc-1.39.0 to use its shipped llvm as a temporary response to the build breakage. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
Hi all, On Fri, 27 Mar 2020, Ken Moffat via blfs-dev wrote: On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs-dev wrote: On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error It seems that using system LLVM is broken with rustc-1.39. For the *second* step, we need to think abou moving to rustc-1.42.0. FYI: I built rustc-1.42 without issues about a week ago (with llvm-9.0.1) as well as just now (with llvm-10.0 and no instruction changes). librsvg-2.48.0, gimp-2.10.18 and firefox-75.0b10 build and run fine with that (llvm-10.0, rustc-1.42, ...) for me. Is there any special reason we would want to upgrade llvm but not rustc? Both are rather ugly packages with pretty long pretty similar build times, but recent rustc versions are available way longer than the recent llvm one. I'd even expect rustc to be easier to upgrade due to fewer stuff to test!? Uwe -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On Fri, Mar 27, 2020 at 08:19:17PM +0100, Pierre Labastie via blfs-dev wrote: > On Fri, 2020-03-27 at 18:24 +, Ken Moffat via blfs-dev wrote: > > On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs- > > dev wrote: > > > On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: > > > > Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an > > > > error: > > > > See attached log (with ~3300 lines cut). Sorry it is a little > > > > long, but > > > > it really looks like some LLVM header file is missing or API has > > > > changed. > > > > > > > > Has anybody seen this too? > > > > > > > > Pierre > > > > > > Yes I have! > > > > > > It seems that using system LLVM is broken with rustc-1.39. I had to > > > do the > > > following to get rustc to build using it's builtin version of LLVM > > > for now > > > (I believe it's LLVM9? LLVM-10 has changed a lot of the public API > > > for > > > applications that use bindings such as rustc). > > > > > > - Comment out the [target.x86_64-unknown-linux-gnu] line > > > > > > - Comment out the llvm-config= line > > > > > > > > > If you are on i686 (untested), comment out the i686 portions of > > > that > > > statement. > > > > > > > > > That will unfortunately force rustc to build using it's builtin > > > LLVM though, > > > which is less than desirable > > > > > > > > > - Doug > > > > > To my surprise, I've found today that the system where I'm waiting > > to test a TL2020-pretest update has enough space to play with > > putting llvm in /opt/llvm. So far, I've merely confirmed that > > clang++ doesn't like it (with both llvm-config entries pointing to > > "/opt/llvm/bin/llvm-config". > > > > For the *first* step I think we will need to revert to the shipped > > llvm (I'm not at all sure about commenting out the target line, I > > think that will make it build for all possible targets, and probably > > be _much_ bigger). > > > > The failing command specified c++-14, but the errors > > look like the sort of scope errors that happen when g++ moves to a > > newer default standard. But since c++-14 is already specified, I > > doubt that trying to override that will be useful. > > > > For the *second* step, we need to think abou moving to rustc-1.42.0. > > Looking at Fresh Ports (for FreeBSD, I think) if I read them right > > they can build all of firefox-esr, firefox-current (74.0) and > > thunderbird without changes from their previous builds. Doesn't > > mean that our builds of the 68.6.0 packages will work, but worth > > trying. I assume that librsvg and cbindgen should be a walk in the > > park, but again obviously need to be tested. And for seamonkey > > there are the patches for rust-1.40+ (one looked large) and perhaps > > the upstream bug at mozilla has been updated. > > > > Tedious. > > > > > > I'll try that (but starting ony tomorrow Western European time). Will > report. Will make some occupation while being locked down... > > Pierre > I've just run a successful build and DESTDIR install, with 8 cores so no timings. Now that I know it does build with the config.toml below (limited to X86 target) I'll take 4 cores offline and do timings and also run the tests to make sure the results from those don't change. Meanwhile, space measurements: ken@deluxe /scratch/ken $du -sch rustc-1.39.0-src/ /tmp/R1390SHIPPED/ 8.0Grustc-1.39.0-src/ 748M/tmp/R1390SHIPPED/ 8.7Gtotal config.toml is as follows, I use -sysllvm and -shipped in the prefix for my own builds, and obviously add those to /etc/ldconfig, so you may want to just use "/opt/rustc-1.39.0" ĸen # - - - start config.toml - - - # see config.toml.example for more possible options [llvm] # use ninja ninja = true # by default, rust will build for a myriad of architectures targets = "X86" [build] # omit docs to save time and space (default is to build them) docs = false # install cargo as well as rust extended = true [install] # after build prefix = "/opt/rustc-1.39.0-shipped" docdir = "share/doc/rustc-1.39.0" [rust] channel = "stable" rpath = false # BLFS does not install the FileCheck executable from llvm, # so disable codegen tests codegen-tests = false # --- end --- -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via blfs- > dev wrote: > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > > > The thread Python multiprocessing checks in chroot is getting > > > long > > > and widening to cover how /dev/shm is treated in LFS. > > > > > > What I'd like to do is put the following note in the BLFS > > > mozilla-derived packages where shm needs to be mounted when the > > > package is configured: > > > > > > - - - > > > If you are compiling this package in chroot you must do two > > > things: > > > > > > First, as the root user, ensure that /dev/shm is mounted: > > > > > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm > > > /dev/shm > > > > > > If you do not do this, configuring will fail with a python > > > traceback > > > report referencing a > > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > > file. > > > > > > Second, as your normal user either ensure the $SHELL environment > > > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > > > - - - > > > > > > Is that acceptable to everyone ? > > > > > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > _exported_. It can be set to /bin/bash without problem. And for me, > > it > > is not exported for _root_ after entering chroot (but it is set): > > > > root [ / ]# echo $SHELL > > /bin/bash > > root [ / ]# env | grep SHELL > > root [ / ]# > > > > Now when doing su - > > > > pierre [ ~ ]$ echo $SHELL > > /bin/bash > > pierre [ ~ ]$ env | grep SHELL > > SHELL=/bin/bash > > pierre [ ~ ]$ > > > > So no need to set/export anything as a user. And SHELL only needs > > to be > > exported as root. > > Pierre > > > > I'm puzzled by that - if it is not set, the configure breaks. Does > SHELL also get queried when root is running the install ? > > When it is set, but not exported, it's not set in ./wmach, so not found... So I'd just suggest something like: Second, you should ensure that the SHELL variable is set and exported to the environment, possibly by prepending SHELL= to the .mach command. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On Fri, 2020-03-27 at 18:24 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs- > dev wrote: > > On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: > > > Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an > > > error: > > > See attached log (with ~3300 lines cut). Sorry it is a little > > > long, but > > > it really looks like some LLVM header file is missing or API has > > > changed. > > > > > > Has anybody seen this too? > > > > > > Pierre > > > > Yes I have! > > > > It seems that using system LLVM is broken with rustc-1.39. I had to > > do the > > following to get rustc to build using it's builtin version of LLVM > > for now > > (I believe it's LLVM9? LLVM-10 has changed a lot of the public API > > for > > applications that use bindings such as rustc). > > > > - Comment out the [target.x86_64-unknown-linux-gnu] line > > > > - Comment out the llvm-config= line > > > > > > If you are on i686 (untested), comment out the i686 portions of > > that > > statement. > > > > > > That will unfortunately force rustc to build using it's builtin > > LLVM though, > > which is less than desirable > > > > > > - Doug > > > To my surprise, I've found today that the system where I'm waiting > to test a TL2020-pretest update has enough space to play with > putting llvm in /opt/llvm. So far, I've merely confirmed that > clang++ doesn't like it (with both llvm-config entries pointing to > "/opt/llvm/bin/llvm-config". > > For the *first* step I think we will need to revert to the shipped > llvm (I'm not at all sure about commenting out the target line, I > think that will make it build for all possible targets, and probably > be _much_ bigger). > > The failing command specified c++-14, but the errors > look like the sort of scope errors that happen when g++ moves to a > newer default standard. But since c++-14 is already specified, I > doubt that trying to override that will be useful. > > For the *second* step, we need to think abou moving to rustc-1.42.0. > Looking at Fresh Ports (for FreeBSD, I think) if I read them right > they can build all of firefox-esr, firefox-current (74.0) and > thunderbird without changes from their previous builds. Doesn't > mean that our builds of the 68.6.0 packages will work, but worth > trying. I assume that librsvg and cbindgen should be a walk in the > park, but again obviously need to be tested. And for seamonkey > there are the patches for rust-1.40+ (one looked large) and perhaps > the upstream bug at mozilla has been updated. > > Tedious. > > I'll try that (but starting ony tomorrow Western European time). Will report. Will make some occupation while being locked down... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs-dev wrote: > > On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: > > Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error: > > See attached log (with ~3300 lines cut). Sorry it is a little long, but > > it really looks like some LLVM header file is missing or API has > > changed. > > > > Has anybody seen this too? > > > > Pierre > > > Yes I have! > > It seems that using system LLVM is broken with rustc-1.39. I had to do the > following to get rustc to build using it's builtin version of LLVM for now > (I believe it's LLVM9? LLVM-10 has changed a lot of the public API for > applications that use bindings such as rustc). > > - Comment out the [target.x86_64-unknown-linux-gnu] line > > - Comment out the llvm-config= line > > > If you are on i686 (untested), comment out the i686 portions of that > statement. > > > That will unfortunately force rustc to build using it's builtin LLVM though, > which is less than desirable > > > - Doug > To my surprise, I've found today that the system where I'm waiting to test a TL2020-pretest update has enough space to play with putting llvm in /opt/llvm. So far, I've merely confirmed that clang++ doesn't like it (with both llvm-config entries pointing to "/opt/llvm/bin/llvm-config". For the *first* step I think we will need to revert to the shipped llvm (I'm not at all sure about commenting out the target line, I think that will make it build for all possible targets, and probably be _much_ bigger). The failing command specified c++-14, but the errors look like the sort of scope errors that happen when g++ moves to a newer default standard. But since c++-14 is already specified, I doubt that trying to override that will be useful. For the *second* step, we need to think abou moving to rustc-1.42.0. Looking at Fresh Ports (for FreeBSD, I think) if I read them right they can build all of firefox-esr, firefox-current (74.0) and thunderbird without changes from their previous builds. Doesn't mean that our builds of the 68.6.0 packages will work, but worth trying. I assume that librsvg and cbindgen should be a walk in the park, but again obviously need to be tested. And for seamonkey there are the patches for rust-1.40+ (one looked large) and perhaps the upstream bug at mozilla has been updated. Tedious. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via blfs-dev wrote: > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > > The thread Python multiprocessing checks in chroot is getting long > > and widening to cover how /dev/shm is treated in LFS. > > > > What I'd like to do is put the following note in the BLFS > > mozilla-derived packages where shm needs to be mounted when the > > package is configured: > > > > - - - > > If you are compiling this package in chroot you must do two things: > > > > First, as the root user, ensure that /dev/shm is mounted: > > > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm > > > > If you do not do this, configuring will fail with a python traceback > > report referencing a > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > file. > > > > Second, as your normal user either ensure the $SHELL environment > > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > > - - - > > > > Is that acceptable to everyone ? > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > _exported_. It can be set to /bin/bash without problem. And for me, it > is not exported for _root_ after entering chroot (but it is set): > > root [ / ]# echo $SHELL > /bin/bash > root [ / ]# env | grep SHELL > root [ / ]# > > Now when doing su - > > pierre [ ~ ]$ echo $SHELL > /bin/bash > pierre [ ~ ]$ env | grep SHELL > SHELL=/bin/bash > pierre [ ~ ]$ > > So no need to set/export anything as a user. And SHELL only needs to be > exported as root. > Pierre > I'm puzzled by that - if it is not set, the configure breaks. Does SHELL also get queried when root is running the install ? ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > The thread Python multiprocessing checks in chroot is getting long > and widening to cover how /dev/shm is treated in LFS. > > What I'd like to do is put the following note in the BLFS > mozilla-derived packages where shm needs to be mounted when the > package is configured: > > - - - > If you are compiling this package in chroot you must do two things: > > First, as the root user, ensure that /dev/shm is mounted: > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm > > If you do not do this, configuring will fail with a python traceback > report referencing a > /usr/lib/pythonN.N/multiprocessing/synchronize.py > file. > > Second, as your normal user either ensure the $SHELL environment > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > - - - > > Is that acceptable to everyone ? > > Sorry for arguing again. The problem is that SHELL needs to be _exported_. It can be set to /bin/bash without problem. And for me, it is not exported for _root_ after entering chroot (but it is set): root [ / ]# echo $SHELL /bin/bash root [ / ]# env | grep SHELL root [ / ]# Now when doing su - pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need to set/export anything as a user. And SHELL only needs to be exported as root. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
On 3/27/20 12:19 PM, Pierre Labastie via blfs-dev wrote: On Fri, 2020-03-27 at 15:47 +, Ken Moffat via blfs-dev wrote: If you wish to change what is in LFS I'll leave that discussion/decision to those with a better understanding than I have. Agreed, we should have another thread for changing lfs on lfs-dev (or not). The only problem we've found is for Mozilla based packages. LFS works as it is. I do not think it needs to be changed. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On 3/27/20 11:02 AM, Ken Moffat via blfs-dev wrote: The thread Python multiprocessing checks in chroot is getting long and widening to cover how /dev/shm is treated in LFS. What I'd like to do is put the following note in the BLFS mozilla-derived packages where shm needs to be mounted when the package is configured: - - - If you are compiling this package in chroot you must do two things: First, as the root user, ensure that /dev/shm is mounted: mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm If you do not do this, configuring will fail with a python traceback report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py file. Second, as your normal user either ensure the $SHELL environment variable is set to /bin/sh, or prepend SHELL=/bin/sh. - - - Is that acceptable to everyone ? It seems like the best approach to me. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
On Fri, 2020-03-27 at 15:47 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 10:11:20PM +0800, Xi Ruoyao via blfs-dev > wrote: > > [...] > > For me, I do not use my normal script for entering chroot when I'm > building a desktop in chroot. Whenever I do that I've normally done > a boot test, and then removed or renamed /tools, so invoking > /tools/bin/env etc doesn't work. I use the commands at the end of chapter 6 (Cleaning up). They do not refer to /tools. Anyway, I agree with what you say below. > > Anyway, I'm not concerned with whether or not the commands for > entering chroot in the LFS book should be changed - I expect to be > able to use the process I mentioned earlier (e.g. when using a rescue > stick) to get into a completed system, and I use the same approach > when building packages in chroot. > > And so far it is only these mozilla derivatives which need shm > during their configure stages. > > If you wish to change what is in LFS I'll leave that > discussion/decision to those with a better understanding than I > have. > Agreed, we should have another thread for changing lfs on lfs-dev (or not). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Python multiprocessing in chroot, proposed note V2
The thread Python multiprocessing checks in chroot is getting long and widening to cover how /dev/shm is treated in LFS. What I'd like to do is put the following note in the BLFS mozilla-derived packages where shm needs to be mounted when the package is configured: - - - If you are compiling this package in chroot you must do two things: First, as the root user, ensure that /dev/shm is mounted: mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm If you do not do this, configuring will fail with a python traceback report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py file. Second, as your normal user either ensure the $SHELL environment variable is set to /bin/sh, or prepend SHELL=/bin/sh. - - - Is that acceptable to everyone ? ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
On Fri, Mar 27, 2020 at 10:11:20PM +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-03-27 11:46 +, Ken Moffat via blfs-dev wrote: > > On Fri, Mar 27, 2020 at 07:03:29AM +0100, Pierre Labastie via blfs-dev > > wrote: > > > Le 27/03/2020 à 00:22, Ken Moffat via blfs-dev a écrit : > > > > On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev > > > > wrote: > > > > > > > > (asking about only one item) > > > > > > If you do not do this, configuring will fail with a python traceback > > > > > > report referencing a > > > > > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > > > > > file and ending 'OSError: [Errno 38] Function not implemented'. > > > > > > (this explanation possibly in italics, i.e. emphasis, except for the > > > > > > filename markup) > > > > > > > > > > As the starter of this thread, I do not see exactly this error, but > > > > > rather: > > > > > > > > > > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in > > > > > > > > > > " function, see issue 3770.") > > > > > ImportError: This platform lacks a functioning sem_open > > > > > implementation, > > > > > therefore, the required synchronization primitives needed will not > > > > > function, > > > > > see issue 3770. > > > > > > > > > > > > > Which package is this which does not mention OSError, please ? > > > > > > > > > > Hmmm, I realize that "as the starter of the thread" may mean I started the > > > thread... Of course I did not. It is the message you mentioned earlier > > > that > > > started that (from Nagasayanam, V.S. on March 21st). The message is about > > > mozjs-60.8.0. And you can see that there is no mention of OSError. > > > > Thanks. That was why it took me so long to originally find my notes > > (for which the key item to grep was OSError). I assumed it might > > have been trimmed off. > > > > > When trying today with host debian, I get: > > > -- > > > 0:23.64 Creating config.status > > > 0:23.76 Traceback (most recent call last): > > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 132, > > > in > > > > > > 0:23.76 sys.exit(main(sys.argv)) > > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 43, > > > in > > > main > > > 0:23.76 return config_status(config) > > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 127, > > > in > > > config_status > > > 0:23.76 return config_status(args=[], **encode(sanitized_config, > > > encoding)) > > > 0:23.76 File > > > "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/config_status.py", > > > line 132, in config_status > > > 0:23.76 reader = BuildReader(env) > > > 0:23.76 File > > > "/sources/firefox/firefox- > > > 68.6.0/python/mozbuild/mozbuild/frontend/reader.py", > > > line 854, in __init__ > > > 0:23.77 self._gyp_worker_pool = > > > ProcessPoolExecutor(max_workers=max_workers) > > > 0:23.77 File > > > "/sources/firefox/firefox- > > > 68.6.0/third_party/python/futures/concurrent/futures/process.py", > > > line 285, in __init__ > > > 0:23.77 EXTRA_QUEUED_CALLS) > > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/__init__.py", line > > > 218, > > > in > > > Queue > > > 0:23.77 return Queue(maxsize) > > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, > > > in > > > __init__ > > > 0:23.77 self._rlock = Lock() > > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line > > > 147, > > > in __init__ > > > 0:23.77 SemLock.__init__(self, SEMAPHORE, 1, 1) > > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line > > > 75, > > > in __init__ > > > 0:23.77 sl = self._semlock = _multiprocessing.SemLock(kind, value, > > > maxvalue) > > > 0:23.77 OSError: [Errno 13] Permission denied > > > 0:23.84 *** Fix above errors and then restart with\ > > > 0:23.84"./mach build" > > > 0:23.84 make: *** [client.mk:115: configure] Error 1 > > > > > > So again different. > > > > OK, Every example mentions multiprocessing/synchronize.py near the > > end, but the exact details of the error message vary. > > > > I'll drop the > > and ending 'OSError: [Errno 38] Function not implemented' > > text. > > > > I guess debian is passing back -EPERM from an attempt to access shm, > > whereas when LFS is the host that gets replaced by Error 38. > > > > > Note that: > > > mount -t tmpfs devshm /dev/shm > > > cures the error > > > > > > Pierre > > > > I can settle for that, but was this build on sysvinit ? From > > xry111's reply, and your earlier points, I got the impression this > > is only a problem on BLFS sysvinit. > > > > If so, the Note should only be added in the sysvinit book. > > No. It's only *not* a problem if the host is LFS-sysvinit or debian. They > uses > /dev/shm -> /run/shm and we explicitly handle this in LFS section 6.2. > For me, I do not use my normal script for entering chroot
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error: See attached log (with ~3300 lines cut). Sorry it is a little long, but it really looks like some LLVM header file is missing or API has changed. Has anybody seen this too? Pierre Yes I have! It seems that using system LLVM is broken with rustc-1.39. I had to do the following to get rustc to build using it's builtin version of LLVM for now (I believe it's LLVM9? LLVM-10 has changed a lot of the public API for applications that use bindings such as rustc). - Comment out the [target.x86_64-unknown-linux-gnu] line - Comment out the llvm-config= line If you are on i686 (untested), comment out the i686 portions of that statement. That will unfortunately force rustc to build using it's builtin LLVM though, which is less than desirable - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] rustc 1.39 broken with llvm 10?
Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error:
See attached log (with ~3300 lines cut). Sorry it is a little long, but
it really looks like some LLVM header file is missing or API has
changed.
Has anybody seen this too?
Pierre
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 codegen artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu, llvm)
Compiling build_helper v0.1.0 (/sources/rust/rustc-1.39.0-src/src/build_helper)
Compiling cc v1.0.35
Compiling rustc_codegen_llvm v0.0.0 (/sources/rust/rustc-1.39.0-src/src/librustc_codegen_llvm)
Compiling rustc_llvm v0.0.0 (/sources/rust/rustc-1.39.0-src/src/librustc_llvm)
error: failed to run custom build command for `rustc_llvm v0.0.0 (/sources/rust/rustc-1.39.0-src/src/librustc_llvm)`
Caused by:
process didn't exit successfully: `/sources/rust/rustc-1.39.0-src/build/x86_64-unknown-linux-gnu/stage0-codegen/release/build/rustc_llvm-95def1069b4f4999/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=REAL_LIBRARY_PATH_VAR
cargo:rerun-if-env-changed=REAL_LIBRARY_PATH
cargo:rerun-if-changed=/usr/bin/llvm-config
cargo:rerun-if-env-changed=LLVM_CONFIG
cargo:rustc-cfg=llvm_component="amdgpu"
cargo:rustc-cfg=llvm_component="asmparser"
cargo:rustc-cfg=llvm_component="bitreader"
cargo:rustc-cfg=llvm_component="bitwriter"
cargo:rustc-cfg=llvm_component="instrumentation"
cargo:rustc-cfg=llvm_component="ipo"
cargo:rustc-cfg=llvm_component="linker"
cargo:rustc-cfg=llvm_component="lto"
cargo:rustc-cfg=llvm_component="x86"
cargo:rustc-cfg=llvm_has_msp430_asm_parser
cargo:rerun-if-changed-env=LLVM_RUSTLLVM
cargo:rerun-if-changed=../rustllvm/.editorconfig
cargo:rerun-if-changed=../rustllvm/README
cargo:rerun-if-changed=../rustllvm/PassWrapper.cpp
cargo:rerun-if-changed=../rustllvm/ArchiveWrapper.cpp
cargo:rerun-if-changed=../rustllvm/rustllvm.h
cargo:rerun-if-changed=../rustllvm/RustWrapper.cpp
cargo:rerun-if-changed=../rustllvm/Linker.cpp
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("2")
HOST = Some("x86_64-unknown-linux-gnu")
CXX_x86_64-unknown-linux-gnu = Some("c++")
CXXFLAGS_x86_64-unknown-linux-gnu = Some("-ffunction-sections -fdata-sections -fPIC -m64")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,mmx,sse,sse2")
running: "c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/usr/include" "-std=c++14" "-fno-exceptions" "-D_GNU_SOURCE" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_X86" "-DNDEBUG" "-o" "/sources/rust/rustc-1.39.0-src/build/x86_64-unknown-linux-gnu/stage0-codegen/x86_64-unknown-linux-gnu/release/build/rustc_llvm-ec98b741bd69569d/out/../rustllvm/PassWrapper.o" "-c" "../rustllvm/PassWrapper.cpp"
cargo:warning=../rustllvm/PassWrapper.cpp: In function ‘void LLVMInitializePasses()’:
cargo:warning=../rustllvm/PassWrapper.cpp:39:3: error: ‘initializeCore’ was not declared in this scope; did you mean ‘LLVMInitializeCore’?
cargo:warning= 39 | initializeCore(Registry);
cargo:warning= | ^~
cargo:warning= | LLVMInitializeCore
cargo:warning=../rustllvm/PassWrapper.cpp:40:3: error: ‘initializeCodeGen’ was not declared in this scope
cargo:warning= 40 | initializeCodeGen(Registry);
cargo:warning= | ^
cargo:warning=../rustllvm/PassWrapper.cpp:41:3: error: ‘initializeScalarOpts’ was not declared in this scope
cargo:warning= 41 | initializeScalarOpts(Registry);
cargo:warning= | ^~~~
cargo:warning=../rustllvm/PassWrapper.cpp:42:3: error: ‘initializeVectorization’ was not declared in this scope
cargo:warning= 42 | initializeVectorization(Registry);
cargo:warning= | ^~~
cargo:warning=../rustllvm/PassWrapper.cpp:43:3: error: ‘initializeIPO’ was not declared in this scope
cargo:warning= 43 | initializeIPO(Registry);
cargo:warning= | ^
cargo:warning=../rustllvm/PassWrapper.cpp:44:3: error: ‘initializeAnalysis’ was not declared in this scope
cargo:warning= 44 | initializeAnalysis(Registry);
cargo:warning= | ^~
cargo:warning=../rustllvm/PassWrapper.cpp:45:3: error: ‘initializeTransformUtils’ was not declared in this scope
cargo:warning= 45 | initializeTransformUtils(Registry);
cargo:warning= | ^~~~
cargo:warning=../rustllvm/PassWrapper.cpp:46:3: error: ‘initializeInstCombine’ was not declared in this scope
cargo:warning= 46 | initializeInstCombine(Registry);
cargo:warning= | ^
cargo:warning=../rustllvm/PassWrapper.cpp:47:3:
Re: [blfs-dev] Python multiprocessing checks in chroot
On 2020-03-27 11:46 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 07:03:29AM +0100, Pierre Labastie via blfs-dev wrote: > > Le 27/03/2020 à 00:22, Ken Moffat via blfs-dev a écrit : > > > On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev > > > wrote: > > > > > > (asking about only one item) > > > > > If you do not do this, configuring will fail with a python traceback > > > > > report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py > > > > > file and ending 'OSError: [Errno 38] Function not implemented'. > > > > > (this explanation possibly in italics, i.e. emphasis, except for the > > > > > filename markup) > > > > > > > > As the starter of this thread, I do not see exactly this error, but > > > > rather: > > > > > > > > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in > > > > > > > > " function, see issue 3770.") > > > > ImportError: This platform lacks a functioning sem_open implementation, > > > > therefore, the required synchronization primitives needed will not > > > > function, > > > > see issue 3770. > > > > > > > > > > Which package is this which does not mention OSError, please ? > > > > > > > Hmmm, I realize that "as the starter of the thread" may mean I started the > > thread... Of course I did not. It is the message you mentioned earlier that > > started that (from Nagasayanam, V.S. on March 21st). The message is about > > mozjs-60.8.0. And you can see that there is no mention of OSError. > > Thanks. That was why it took me so long to originally find my notes > (for which the key item to grep was OSError). I assumed it might > have been trimmed off. > > > When trying today with host debian, I get: > > -- > > 0:23.64 Creating config.status > > 0:23.76 Traceback (most recent call last): > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 132, in > > > > 0:23.76 sys.exit(main(sys.argv)) > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 43, in > > main > > 0:23.76 return config_status(config) > > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 127, in > > config_status > > 0:23.76 return config_status(args=[], **encode(sanitized_config, > > encoding)) > > 0:23.76 File > > "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/config_status.py", > > line 132, in config_status > > 0:23.76 reader = BuildReader(env) > > 0:23.76 File > > "/sources/firefox/firefox- > > 68.6.0/python/mozbuild/mozbuild/frontend/reader.py", > > line 854, in __init__ > > 0:23.77 self._gyp_worker_pool = > > ProcessPoolExecutor(max_workers=max_workers) > > 0:23.77 File > > "/sources/firefox/firefox- > > 68.6.0/third_party/python/futures/concurrent/futures/process.py", > > line 285, in __init__ > > 0:23.77 EXTRA_QUEUED_CALLS) > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/__init__.py", line 218, > > in > > Queue > > 0:23.77 return Queue(maxsize) > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in > > __init__ > > 0:23.77 self._rlock = Lock() > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line > > 147, > > in __init__ > > 0:23.77 SemLock.__init__(self, SEMAPHORE, 1, 1) > > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line > > 75, > > in __init__ > > 0:23.77 sl = self._semlock = _multiprocessing.SemLock(kind, value, > > maxvalue) > > 0:23.77 OSError: [Errno 13] Permission denied > > 0:23.84 *** Fix above errors and then restart with\ > > 0:23.84"./mach build" > > 0:23.84 make: *** [client.mk:115: configure] Error 1 > > > > So again different. > > OK, Every example mentions multiprocessing/synchronize.py near the > end, but the exact details of the error message vary. > > I'll drop the > and ending 'OSError: [Errno 38] Function not implemented' > text. > > I guess debian is passing back -EPERM from an attempt to access shm, > whereas when LFS is the host that gets replaced by Error 38. > > > Note that: > > mount -t tmpfs devshm /dev/shm > > cures the error > > > > Pierre > > I can settle for that, but was this build on sysvinit ? From > xry111's reply, and your earlier points, I got the impression this > is only a problem on BLFS sysvinit. > > If so, the Note should only be added in the sysvinit book. No. It's only *not* a problem if the host is LFS-sysvinit or debian. They uses /dev/shm -> /run/shm and we explicitly handle this in LFS section 6.2. For other hosts, /dev/shm is a mount point of a seperated tmpfs, with perm 0777. In mount -v --bind /dev $LFS/dev, --bind is not recursive so $LFS/dev/shm becames a empty directory, owned by root:root with perm 0755. So normal users won't be able to use POSIX shared memory and semaphore. I think we should change the command in 6.2: if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm) fi to mount -v -t tmpfs
[blfs-dev] proposal: add -DLLVM_BINUTILS_INCDIR=/usr/include for LLVM
It would make LLVM building system to build LLVMgold.so with Binutils headers installed in LFS, which is a linker plugin so we can use "clang -flto hw.c". -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Missing kadm5.acl file for MIT-Kerberos?
Each time krb5 is started, I get:
Starting Kerberos administrative server kadmindkadmind: Cannot open
/var/lib/krb5kdc/kadm5.acl: No such file or directory while
initializing ACL file, aborting
The kadamind daemon is therefore not started.
There are several possibilities if we not want to configure acl's:
a) add acl_file = "" under the realm in /etc/krb5.conf
This has two drawbacks: (i) the 'acl_file =' should be present
only on the kdc host, while an user might copy krb5.conf to a
client host. (ii) if an user later creates an acl file, he/she
may wonder why it is not taken into account.
b) create a file /var/lib/krb5kdc/kdc.conf, containing:
[realms]
= {
acl_file = ""
}
Drawback: new file. But normally kdc.conf is only present on the KDC
host.
c) create an empty /var/lib/krb5kdc/kadm5.acl
Advantage: this file can be augmented later. But needs an
explanation in the book
I think I'd slightly prefer c).
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
On Fri, Mar 27, 2020 at 07:03:29AM +0100, Pierre Labastie via blfs-dev wrote: > Le 27/03/2020 à 00:22, Ken Moffat via blfs-dev a écrit : > > On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev > > wrote: > > > > (asking about only one item) > >> > >>> > >>> If you do not do this, configuring will fail with a python traceback > >>> report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py > >>> file and ending 'OSError: [Errno 38] Function not implemented'. > >>> (this explanation possibly in italics, i.e. emphasis, except for the > >>> filename markup) > >> > >> As the starter of this thread, I do not see exactly this error, but rather: > >> > >> File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in > >> > >> " function, see issue 3770.") > >> ImportError: This platform lacks a functioning sem_open implementation, > >> therefore, the required synchronization primitives needed will not > >> function, > >> see issue 3770. > >> > > > > Which package is this which does not mention OSError, please ? > > > > Hmmm, I realize that "as the starter of the thread" may mean I started the > thread... Of course I did not. It is the message you mentioned earlier that > started that (from Nagasayanam, V.S. on March 21st). The message is about > mozjs-60.8.0. And you can see that there is no mention of OSError. Thanks. That was why it took me so long to originally find my notes (for which the key item to grep was OSError). I assumed it might have been trimmed off. > When trying today with host debian, I get: > -- > 0:23.64 Creating config.status > 0:23.76 Traceback (most recent call last): > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 132, in > > 0:23.76 sys.exit(main(sys.argv)) > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 43, in > main > 0:23.76 return config_status(config) > 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 127, in > config_status > 0:23.76 return config_status(args=[], **encode(sanitized_config, > encoding)) > 0:23.76 File > "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/config_status.py", > line 132, in config_status > 0:23.76 reader = BuildReader(env) > 0:23.76 File > "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/frontend/reader.py", > line 854, in __init__ > 0:23.77 self._gyp_worker_pool = > ProcessPoolExecutor(max_workers=max_workers) > 0:23.77 File > "/sources/firefox/firefox-68.6.0/third_party/python/futures/concurrent/futures/process.py", > line 285, in __init__ > 0:23.77 EXTRA_QUEUED_CALLS) > 0:23.77 File "/usr/lib/python2.7/multiprocessing/__init__.py", line 218, in > Queue > 0:23.77 return Queue(maxsize) > 0:23.77 File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in > __init__ > 0:23.77 self._rlock = Lock() > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 147, > in __init__ > 0:23.77 SemLock.__init__(self, SEMAPHORE, 1, 1) > 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, > in __init__ > 0:23.77 sl = self._semlock = _multiprocessing.SemLock(kind, value, > maxvalue) > 0:23.77 OSError: [Errno 13] Permission denied > 0:23.84 *** Fix above errors and then restart with\ > 0:23.84"./mach build" > 0:23.84 make: *** [client.mk:115: configure] Error 1 > > So again different. OK, Every example mentions multiprocessing/synchronize.py near the end, but the exact details of the error message vary. I'll drop the and ending 'OSError: [Errno 38] Function not implemented' text. I guess debian is passing back -EPERM from an attempt to access shm, whereas when LFS is the host that gets replaced by Error 38. > Note that: > mount -t tmpfs devshm /dev/shm > cures the error > > Pierre I can settle for that, but was this build on sysvinit ? From xry111's reply, and your earlier points, I got the impression this is only a problem on BLFS sysvinit. If so, the Note should only be added in the sysvinit book. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
Le 27/03/2020 à 00:22, Ken Moffat via blfs-dev a écrit : > On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev wrote: > > (asking about only one item) >> >>> >>> If you do not do this, configuring will fail with a python traceback >>> report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py >>> file and ending 'OSError: [Errno 38] Function not implemented'. >>> (this explanation possibly in italics, i.e. emphasis, except for the >>> filename markup) >> >> As the starter of this thread, I do not see exactly this error, but rather: >> >> File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in >> >> " function, see issue 3770.") >> ImportError: This platform lacks a functioning sem_open implementation, >> therefore, the required synchronization primitives needed will not function, >> see issue 3770. >> > > Which package is this which does not mention OSError, please ? > Hmmm, I realize that "as the starter of the thread" may mean I started the thread... Of course I did not. It is the message you mentioned earlier that started that (from Nagasayanam, V.S. on March 21st). The message is about mozjs-60.8.0. And you can see that there is no mention of OSError. When trying today with host debian, I get: -- 0:23.64 Creating config.status 0:23.76 Traceback (most recent call last): 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 132, in 0:23.76 sys.exit(main(sys.argv)) 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 43, in main 0:23.76 return config_status(config) 0:23.76 File "/sources/firefox/firefox-68.6.0/configure.py", line 127, in config_status 0:23.76 return config_status(args=[], **encode(sanitized_config, encoding)) 0:23.76 File "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/config_status.py", line 132, in config_status 0:23.76 reader = BuildReader(env) 0:23.76 File "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/frontend/reader.py", line 854, in __init__ 0:23.77 self._gyp_worker_pool = ProcessPoolExecutor(max_workers=max_workers) 0:23.77 File "/sources/firefox/firefox-68.6.0/third_party/python/futures/concurrent/futures/process.py", line 285, in __init__ 0:23.77 EXTRA_QUEUED_CALLS) 0:23.77 File "/usr/lib/python2.7/multiprocessing/__init__.py", line 218, in Queue 0:23.77 return Queue(maxsize) 0:23.77 File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in __init__ 0:23.77 self._rlock = Lock() 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 147, in __init__ 0:23.77 SemLock.__init__(self, SEMAPHORE, 1, 1) 0:23.77 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__ 0:23.77 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) 0:23.77 OSError: [Errno 13] Permission denied 0:23.84 *** Fix above errors and then restart with\ 0:23.84"./mach build" 0:23.84 make: *** [client.mk:115: configure] Error 1 So again different. Note that: mount -t tmpfs devshm /dev/shm cures the error Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
