On Tue, 16 Jul 2019 23:43:40 +0100 Ken Moffat via blfs-support 
<[email protected]> wrote:

> On Tue, Jul 16, 2019 at 10:44:23PM +0200, Stephen Berman via blfs-support 
> wrote:
>> Although PyQt4 is not a BLFS package nor a direct dependency of one, it
>> is apparently a required dependency to build the GUI of hplip, which,
>> while also not a BLFS package, is mentioned as optional for cups and
>> cups-filters, and for SANE as something "you may need" (and indeed I
>> do), so I think my issue is not completely off-topic.  
>> 
>> I tried to build PyQt4 from source downloaded from
>> https://www.riverbankcomputing.com/software/pyqt/download, after
>> installing the Python SIP library, also available there.  The SIP build
>> and installation succeeded, but after configuring PyQt4, make failed:
>> 
>>    
>> /sources/PyQt4_gpl_x11-4.12.3/QtCore/sipQtCoreQAbstractEventDispatcher.cpp:115:10:
>>  error: ‘void sipQAbstractEventDispatcher::registerTimer(int, int, 
>> QObject*)’ marked ‘override’, but does not override
>>    void registerTimer(int,int, ::QObject*) SIP_OVERRIDE;
>>         ^~~~~~~~~~~~~
>>    make[1]: *** [Makefile:6368: sipQtCoreQAbstractEventDispatcher.o] Error 1
>>    make[1]: Leaving directory '/sources/PyQt4_gpl_x11-4.12.3/QtCore'
>>    make: *** [Makefile:66: sub-QtCore-make_first-ordered] Error 2
>> 
>> This happened both when I configured with Python2 and with Python3.
>> A web search didn't help me with this.  Does anyone here have an idea?
>> Has anyone here succeeded in building PyQt4 and the hplip GUI with Qt5
>> from BLFS 8.4?
>> 
>> (The hplip config also allows using PyQt5, and that is installable via
>> pip3, and I did install it and configured hplip with it, but still the
>> hplip GUI was not built, so it seems to require PyQt4.)
>> 
>> Steve Berman
>
> First, even if the package was not mentioned in the book, for BLFS
> it is not off-topic, merely a path (much) less followed.
>
> Not something I've ever needed, but this looks like it might be the
> sort of problem caused by newer versions of C++.  Alternatively,
> perhaps a missing dependency.  Googling for an ebuild suggests it has
> been dropped by gentoo, but it looks as if both Arch and fedora have
> recent updates.
>
> These days, all I can find for fedora is srpms (need cpio and an
> rpm2cpio script), so I can't quickly tell if their builds match what
> Arch have.
>
> For Arch:
>
> https://aur.archlinux.org/aur.git/tree/PKGBUILD?h=pyqt4
>
> I've no idea what the configure switches do, but they seem to depend
> on something called sip and variations of that.  Those are probably
> also in A UR and perhaps related to their --no-sip-files switch, so
> maybe the package includes its own variants, best to check the
> configure-ng.py script in case it says anything useful. [1.]
> They also build for both Python3 (which they call Python) and
> Python2.
>
> For fedora, it is in:
>
> https://dl.fedoraproject.org/pub/fedora/linux/updates/30/Everything/SRPMS/Packages/p
>
> Again, they probably mean Python3 if they say 'Python'.
>
> 1. Just in case you were not aware, I have a very low opinion about
> the information provided, or more likely not provided, by configure
> scripts and build scripts which use either flavour of Python.

Thanks for the links.  The versions are the same as what I downloaded
from upstream, though as you say, downstream may have modified them.  I
haven't tried them yet because I found instructions at
https://developers.hp.com for installing hplip with PyQt5, which I had
installed with pip3.  To make the build succeed I had to pass
PYTHON=python3 to configure.  However, the resulting hp-* executables in
/usr/bin failed to execute, because they are symlinks to Python modules
which all begin with this line: #!/usr/bin/env python, so they use
Python2.  I guess a suitable sed would fix that, but in the mean time,
this invocation succeeded: python3 /usr/share/hplip/setup.py, and the
GUI popped up.  So this was progess.

The next step was to install (via another hp-* GUI module) the binary
plugin needed to use the scanner; this also succeeded, but when I then
ran xsane, it immediately segfaulted.  There was no output in the shell,
but /var/log/sys.log had this:

xsane[18427]: segfault at 0 ip 00007fe1235d14ab sp 00007ffe5b942e10 error 4 in 
libc-2.29.so[7fe123584000+149000]
Code: ff ff ff 48 89 c6 e9 6c 32 fb ff 0f 1f 40 00 85 f6 0f 8e 38 01 00 00 41 
54 41 89 f0 49 89 fc 55 53 83 fe 01 0f 84 35 01 00 00 <8b> 0a 89 c8 25 00 80 00 
00 75 5b 4c 8b 8a 88 00 00 00 64 4c 8b 14

I also tried scanimage and /usr/share/hplip/scan.py and both also
immediately segfaulted and sys.log showed exactly the same entries
again.  Prior to installing the plugin, xsane had started and recognized
the scanner but immediately threw an I/O error; scanimage also
recognized the scanner.  I thought maybe these programs were now trying
to access memory that had been overwritten by the plugin installation,
but after rebooting they still segfaulted with the same log output.

I searched the web but found nothing relevant.

Steve Berman
-- 
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