On 2020-03-27 11:46 +0000, 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 > > > > <module> > > > > " 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 > > <module> > > 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 devshm $LFS/dev/shm which works for both cases (/dev/shm is a link to /run/shm, or /dev/shm is a seperated tmpfs). -- Xi Ruoyao <[email protected]> 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
