> Sent: Friday, July 26, 2019 at 7:14 AM > From: "Stephen Berman via blfs-support" > <[email protected]> > To: "Ken Moffat via blfs-support" <[email protected]> > Cc: "Stephen Berman" <[email protected]> > Subject: [blfs-support] scanimage crashes with hplip plug-in (was: [BLFS 8.4] > PyQt4 build failure) > > On Fri, 19 Jul 2019 02:21:28 +0100 Ken Moffat via blfs-support > <[email protected]> wrote: > > > On Thu, Jul 18, 2019 at 11:50:03PM +0200, Stephen Berman wrote: > >> On Thu, 18 Jul 2019 21:53:59 +0100 Ken Moffat via blfs-support > >> <[email protected]> wrote: > >> > >> Yes, I will definitely try to figure out what openSUSE installs to see > >> what I'm missing. > >> > >> >> Thread 1 "scanimage" received signal SIGSEGV, Segmentation fault. > >> >> _IO_fgets (buf=buf@entry=0x7fffffffb9f0 "", n=n@entry=128, > >> >> fp=fp@entry=0x0) > >> >> at iofgets.c:47 > >> >> 47 iofgets.c: No such file or directory. > >> > > >> > Google suggests this happens because the result of fopen is not > >> > checked before using fgets to read from the file. And iofgets.c is > >> > part of glibc. > >> > >> I don't know what to do with that information... > >> > > Me neither! I think it means that the binary wants to open > > something and assumes it must be present. But given the weirdnesses > > of devices attached to usb ports (e.g. my epson usb printer claims > > to have something else - usb storage, I think), it might want to > > write to it (e.g. group write permission). > > > > Christopher replied with a list of what hp expects to be installed > > (although suggesting that Qt >= 3.3 is needed doesn't give a lot of > > confidence for current versions of everything), I would check that > > list against what you have in both LFS and OpenSuSe. And since we > > none of us have any idea what the binary is likely to do, perhaps > > check ownership of those files, the binary, and general system files > > on both systems. > > I downloaded the relevant source RPMs from the openSUSE Tumbleweed repo, > converted them to tar.gz and tried to build them according to the RPM > spec files, but in the case of hplip there were a lot of > openSUSE-specific bits and the specs were too complicated for me to > follow completely. But I did end up with an apparently working hplip, > and was, as before, able to install the printer queue and print a test > page. But as soon as I installed the plug-in for the scanner, scanimage > again segfaulted. There are a lot of entries in the openSUSE udev > scanner rules file that the vanilla hplip of the same version doesn't > have, but adding them didn't make a difference (in the udev rules, > openSUSE uses the lp group where BLFS uses the scanner group, but I > changed the entries I added accordingly). Comparing the hplip files in > Tumbleweed and BLFS, I didn't notice any permission differences. The > segfault seems to be at a low level; there are some library differences > between my Tumbleweed and BLFS systems (e.g libjpeg.so.8 > vs. libjpeg.so.62) but I doubt that's the cause of the crash. > > I've retitled this thread, since the original title is no longer the > problem. Is there anyone here who has built hplip in BLFS, installed > the scanner plug-in and can use scanimage and xsane? > > Steve Berman > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page >
Hello, I hate to be the one who says this, but as you have probably already realized by now, there is not going to be much that people on this list are going to be able to suggest to correct this, as it is most likely going to end up being an issue with the binary. I did read that the configure line and make have to be run as a normal user, so make sure that you are not running either of these as root. Only the make install is to be done as root. I do not know if the plugin itself is a pre-compiled closed source binary that gets downloaded and put in place by scripts or not, but if that is the case, bear in mind that many of the distro's have a 32 bit and a 64 bit version. You need to make sure that it is a version that has been compiled for your particular hardware. Also check that the installation has not done something unexpected by placing one or more files in either the /usr/local location, or in /usr/lib64. These are the only suggestions that I can think of. Once you have double checked all these, if it is indeed a closed binary, it would be time to locate their current bug tracker and post a bug report. It may be that on lfs/blfs that a newer version of a package has had a change made in it that is causing the issue. Regards, Christopher. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
