On Sun, Sep 15, 2019 at 09:14:44PM -0400, Jared Stevens via blfs-support wrote:
> (If I am continuing to top-post still, would someone be able to tell me the
> proper way to reply to the thread? Currently, I am simply clicking "Reply"
> in Gmail to the latest email in the thread that I have)
> 

Gmail's web interface is pretty horrible - see comments on the
kernel list whenever people try to use it to send patches inline.

In reply, before you type anything you should see '...' at the
bottom of the panel, with text of 'Show trimmed content' when you
mouse over it.

Click on that '...' - you will see the original text, with '> ' at
the start of each line (or multiple > where this is not the first
post in the thread).  Keep the 'on someday at sometime someone wrote'
line(s) but delete everything which is not relevant to your reply.

And put each item of your reply after the text you are replying to or
commenting on.

> Just to provide an update for you all, I uninstalled Python 2 and
> reinstalled it along with all modules in the book (without pip) with no
> change.
> 

So, above I put the 'HOWTO', here I would ordinarily only keep
your paragraph if I wanted to sound off about Python ;-)  I hope
that part of my reply has made the 'do not top post' clearer.

> So after digging deeper into the log, I decided to visit Debian's package
> repository site for their Jessie distribution and downloaded the source
> tarbell for MarkupSafe-0.23 just for the heck of it.
> 
> I installed it identically to how the book installs MarkupSafe-1.1.1 except
> I installed the Python 2 module instead like so:
> 
> `python2 setup.py build &&
> 
>  python2 setup.py install --optimize=1`
> 
> 
> Afterwards, I attempted the Jinja2 module install again. This time, it was
> able to "see" the MarkupSafe module and used 1.1.1 to successfully install
> the Python 2 module.
> 

That is worrying.  As I think I said, I'm sticking with the 5.12
series for my own builds and I've not been aware of Jinja2 being
used until your post a few hours ago.  So, I don't see *why* that
would help, and maybe it was a temporary problem at pypi (with
python3 we enable pypi and I've sometimes seen similar problems).
But that is now water under the bridge.

However -
> 
> However, I am still unable to install Qt5WebEngine. While the above fixes
> my first issue that caused a build failure, I am now experiencing yet
> another build failure MUCH later into the process. Here is the output:
> 
> `In member function ‘void SocketCanBackend::readSocket()’:
> socketcanbackend.cpp:697:41: error: ‘SIOCGSTAMP’ was not declared in this
> scope
>          if (Q_UNLIKELY(ioctl(canSocket, SIOCGSTAMP, &timeStamp) < 0)) {
>                                          ^~~~~~~~~~
> /sources/qt-everywhere-src-5.13.0/qtbase/include/QtCore/../../src/corelib/global/qcompilerdetection.h:237:49:
> note: in definition of macro ‘Q_UNLIKELY’
>  #  define Q_UNLIKELY(expr)  __builtin_expect(!!(expr), false)
>                                                  ^~~~
> socketcanbackend.cpp:697:41: note: suggested alternative: ‘SIOCSARP’
>          if (Q_UNLIKELY(ioctl(canSocket, SIOCGSTAMP, &timeStamp) < 0)) {

(re top-posting - I went to trim everything after that, at which
point the earlier replies showed up - that is why top-posting is
annoying)

The SIOCGSTAMP problems were caused by a change in the linux headers
in the 5.2 kernel.  We initially had seds in the affected packages,
but it turned out that glibc upstream had a fix which did not make
it into the 2.30 release.

That fix is in LFS chapter 6 glibc, a sed to "Fix a problem
introduced with the linux-5.2 kernel".  You seem to have missed that
when building LFS ?

Before we put the fix into LFS, we had a sed in
qtwebengine-5.12.4:

sed -i 's/SIOCGSTAMP/0x8906/' \
 src/3rdparty/chromium/third_party/webrtc/rtc_base/physicalsocketserver.cc

We also had similar seds in one or two other places (ISTR firefox
was affected), it might be that one or two other packages will bite
you in a similar way - in each case, SIOCGSTAMP should be changed to
0x8906.  Since you are now using 5.13 I suppose it is possible that
the SIOCGSTAMP definition might be in a different file.

ĸen
-- 
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to