[blfs-dev] Firefox-57.0.1 build fails if /run/shm has incorrect permissions when building Python 2

Ryan Marsaw rmarsaw at personainternet.com
Wed Dec 27 11:57:19 PST 2017


Hello BLFS editors:

First, a disclaimer: After I build my LFS system, I chroot into the new build
right away to install my BLFS packages. I do not reboot beforehand. This is
important when reading the rest of this message.

Here's the issue:

When attempting to build Firefox-57.0.1 I get the following error shortly after
I run "make -f client.mk build:"

 0:21.05 Creating config.status
 0:21.22 Traceback (most recent call last):
 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 124, in <module>
 0:21.22 sys.exit(main(sys.argv))
 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 34, in main
 0:21.22 return config_status(config)
 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 119, in config_status
 0:21.22 return config_status(args=[], **encode(sanitized_config, encoding))
 0:21.22 File "/usr/src/scm/gecko-dev/python/mozbuild/mozbuild/config_status.py", line 136, in config_status
 0:21.22 reader = BuildReader(env)
 0:21.22 File "/usr/src/scm/gecko-dev/python/mozbuild/mozbuild/frontend/reader.py", line 868, in __init__
 0:21.22 self._gyp_worker_pool = ProcessPoolExecutor(max_workers=max_workers)
 0:21.22 File "/usr/src/scm/gecko-dev/third_party/python/futures/concurrent/futures/process.py", line 285, in __init__
 0:21.22 EXTRA_QUEUED_CALLS)
 0:21.22 File "/usr/lib/python2.7/multiprocessing/__init__.py", line 217, in Queue
 0:21.22 from multiprocessing.queues import Queue
 0:21.22 File "/usr/src/scm/gecko-dev/build/mach_bootstrap.py", line 351, in __call__
 0:21.22 module = self._original_import(name, globals, locals, fromlist, level)
 0:21.22 File "/usr/lib/python2.7/multiprocessing/queues.py", line 48, in <module>
 0:21.22 from .synchronize import Lock, BoundedSemaphore, Semaphore, Condition
 0:21.22 File "/usr/src/scm/gecko-dev/build/mach_bootstrap.py", line 351, in __call__
 0:21.22 module = self._original_import(name, globals, locals, fromlist, level)
 0:21.22 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in <module>
 0:21.22 " function, see issue 3770.")
 0:21.22 ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
 0:21.28 *** Fix above errors and then restart with\
 0:21.28 "/usr/bin/make -f client.mk build"
 0:21.28 make: *** [client.mk:388: configure] Error 1

At first I thought this was a problem with Firefox, but after reading through
the traceback I realized that it was Firefox attempting to run a Python script
(synchronize.py), and it's that script that generates the above error.

Some searching into this error led me to conclude that the culprit may be the
permissions on /run/shm, combined with the installation of Python 2. Although
Python 2 itself builds fine no matter what the permissions of /run/shm are, the
effects are not noticeable until one builds Firefox-57.0.1.

As I mentioned above, I tend not to reboot my PC after building LFS, but
rather, I chroot into the new LFS build and then install all my BLFS packages.
Because I haven't rebooted, the permissions on /run/shm are still the same as
when they were set in LFS section 6.2. Preparing Virtual Kernel File Systems,
which is drwxr-xr-x. It's not until a reboot of the system is made that
permissions on /run/shm are changed to drwxrwxrwt.

It would appear that Python 2 builds differently depending on the permissions
of /run/shm. As a test, I ran Python's configuration (as per BLFS
instructions) with the two different permissions on /run/shm. Here's what I
found:

With /run/shm permissions at drwxr-xr-x:
.
.
checking whether POSIX semaphores are enabled... no
checking for broken sem_getvalue... yes
.
.

With /run/shm permissions at drwxrwxrwt:
.
.
checking whether POSIX semaphores are enabled... yes
checking for broken sem_getvalue... no
.
.

It's only when Python 2 is built with /run/shm permissions at drwxrwxrwt that
Firefox-57.0.1 builds without any issues.

I don't know if the LFS editors assume that a user will reboot a machine before
building BLFS packages, but this information might come in handy for anyone who
(like me) does not reboot until after BLFS is built (or, at least until after
Python 2 is built).

For what it's worth, in LFS section 6.2. Preparing Virtual Kernel File
Systems, I change the permissions on /run/shm as so:

if [ -h $LFS/dev/shm ]; then
 install -v -dm 1777 $LFS$(readlink $LFS/dev/shm)
fi

Happy Holidays, and keep up the excellent work!

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-dev/attachments/20171227/b2b9ea32/attachment.html>


More information about the blfs-dev mailing list