On Fri, Mar 22, 2019 at 05:38:18PM -0700, Mark Wigzell via blfs-dev wrote:
> Hey guys, I recently added some BLFS support and got "startx" running, at
> which point I decided to run "firefox" so I can follow along with further
> installation of packages. However "firefox" wouldn't build because it turns
> out "python2" determined (during its configuration), that POSIX semaphores
> were not supported. This occurred both when booted and also when "chrooted"
> to LFS partition. Up until success with "startx" I was mostly running with
> "chroot" since that is easier.

A common-enough way of building a desktop.  There are a few packages
where the book notes that SHELL might need to be set in chroot
(particularly mozilla packages) but I don't recall anyone reporting
a similar problem with python2.

> The failure occurred when testing the result of generating a code file to
> use "sem_open()". When I tried that code myself, it built and ran
> perfectly.
> So my temp. solution is to force the configure of Python2 so that it
> believes that the test worked. After that I could build Python2 with
> sempahores enabled, and thus firefox went without a hitch.

I will start by noting that on my builds there is an enormous
distance between getting startx to run, and building firefox. Apart
from gtk{2,3} with their deps there are also llvm if you did not
already build it for Mesa, rustc, and even node-js takes time.  You
make that sound like a simple journey, I beg leave to differ.

However, for the point about python2 and POSIX - on desktop systems
I always build python2 in chroot before I boot the new system (and
similarly I build many other packages in chroot).  A quick look at a
random 8.3 build suggests POSIX was supported.  So, please:

What was the actual error in python2 ?

And, just in case it is something odd, what kernel was your host
system running (i.e. distro/version, or self-compiled and version) ?

You clearly know enough to "persuade" python2 that the test will
pass, so you are not a novice.  Is thee anything "unusual" about how
you built LFS ?

And I hope you are using the current version of firefox (which needs
the version of rustc from the 8.4 book), because pretty much every
new version includes vulnerability fixes - although the security
part of the release notes does not always mention them on point
releases.

Overall, we only really care about the current release (and some of
us don't really care about that!), but I've managed to upgrade to
firefox-66.0 this week on old systems as far back as LFS/BLFS-8.0,
albeit with various other vulnerability fixes and various
differences or workarounds (for example, on really old systems I had
to upgrade llvm to 6.0.1 for a previous firefox release - that is
also good enough for 66.0 although other packages needed to be
updated).

But if you are using the versions in 8.3, I recommend that you build
the latest firefox-60.X esr version - that should save having to
rebuild rustc.

Oh, and yes, using firefox makes reading the book and searching re
problems a lot easier than e.g. 'links -g'.  And despite the many
dependencies it is probably still a lighter build than falkon or
epiphany.  But I remain puzzled by your problem.

ĸen
-- 
  It is said that there are two great unsolved problems in computer
  science: naming, cache invalidation, and off-by-one errors.
                         -- Ben Bullock
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to