PIL selftest.py fails for Centos 6 64-bit Error: Jpeg Decoder not Available - centos

I am having difficulty on my server trying to get the selftest.py to run successfully.
I am trying to get PIL 1.1.7 working with Python 2.4.4 (Are the versions compatible?)
When the install is preformed like so:
# python2.4 setup.py install
running install
running build
running build_py
running build_ext
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version 1.1.7
platform linux2 2.4.6 (#1, Dec 21 2012, 14:54:30)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]
--------------------------------------------------------------------
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.
To check the build, run the selftest.py script.
running build_scripts
running install_lib
running install_scripts
changing mode of /usr/local/bin/pilconvert.py to 755
changing mode of /usr/local/bin/pilprint.py to 755
changing mode of /usr/local/bin/pilfile.py to 755
changing mode of /usr/local/bin/pilfont.py to 755
changing mode of /usr/local/bin/pildriver.py to 755
creating /usr/local/lib/python2.4/site-packages/PIL.pth
Everything seems handy dandy. Jpeg support is available and all is happy. But the selftest.py however is a different story:
# python2.4 /usr/local/src/Imaging-1.1.7/selftest.py
--------------------------------------------------------------------
PIL 1.1.7 TEST SUMMARY rc/Imaging-1.1.7]# yum install libjpeg62-devel zlib1g-devel libfreetype6-devel liblcms1-develp
--------------------------------------------------------------------
Python modules loaded from ./PIL
Binary modules loaded from ./PIL
--------------------------------------------------------------------
--- PIL CORE support ok
*** TKINTER support not installed
*** JPEG support not installed
*** ZLIB (PNG/ZIP) support not installed
--- FREETYPE2 support ok
*** LITTLECMS support not installed
--------------------------------------------------------------------
Running selftest:
*****************************************************************
Failure in example:
try:
_info(Image.open(os.path.join(ROOT, "Images/lena.jpg")))
except IOError, v:
print v
from line #24 of selftest.testimage
Expected: ('JPEG', 'RGB', (128, 128))
Got: decoder jpeg not available
1 items had failures:
1 of 57 in selftest.testimage
***Test Failed*** 1 failures.
*** 1 tests of 57 failed.
I get the dreaded Jpeg decoder not available.
I've tried a variety of things. I changed the setup to point to usr/lib64 that didn't work. I made some symbolic links in the usr/lib to point to the libjpeg.so file, that also didn't work. I went back and forth with the tech guys at our server hosting place and they aren't understanding the issue and it's like talking to a wall. I am really stuck. The only thing I haven't tried is the PiP but I didn't try that because I don't know how that works exactly. So I want to avoid that.
Is there a compatibility issue or a setting I just don't have quite right?
Thank you for the assistance.
--UPDATE--
Working on this problem again these days
I've tested Centos 5 & 6 32-bit And everything installs like a charm, but 64-bit I'm still having issues.
It seems like the selftest works with the stock python2.6 but not with python2.4. Pil 1.1.7 is compatable with 2.4.4 but I think there is a problem with the libraries in 64-bit. Still searching for a solution.

After extensive testing it's just not possible.
I'm sure it can be done but the steps it would require to get it down would be so intensive that it would make it difficult to gaurentee the stability of the server/system.
The problem really lies in the 64-bit system. The Python-Imagining would work with python 2.4 if python 2.4 was compiled as 32-bit. However even if you get Python-2.4 compiled into 32-bit it has a hard time with the libraries since everything in Centos is build for the 64 arch. And getting those additional libraries is cumbersome since the repos won't include the structures you need to get it working. It's just, annoying. It's not feasible to go hunting around in circles and the time spent trying to support such a limping system is wasted. And possibly puts the system at risk.
No, it's not possible to install PIL for Python 2.4 on a 64-bit machine.

In my case we had no support of all the libraries in PIL (CentOS 6, x64)
*** TKINTER support not available
*** JPEG support not available
--- ZLIB (PNG/ZIP) support available
*** FREETYPE2 support not available
*** LITTLECMS support not available
So we used following:
yum install freetype freetype-devel libpng libpng-devel libjpeg libjpeg-devel
And now we have
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available

3 years later, I know, but this can work just fine! The standard build process will not look for libraries in /usr/lib64, but you can't specify a library path when running setup.py build, so you need to rebuild the binaries afterwards in a separate step:
yum install freetype-devel libpng-devel libjpeg-turbo-devel libzip-devel lcms-devel
pip download PIL
unzip pil-1.1.7.zip
cd pil-1.1.7
./setup.py build
./setup.py build_ext -L /usr/lib64/:/usr/local/lib64 --force
./setup.py install --prefix /usr/local/python27 --force --skip-build
This is on Scientific Linux 6.7 64-bit, using Python 2.7 compiled from source.

Related

stack-protector enabled but compiler support broken while installing VirtualBox Guest Additions with devtoolset-8

Note: This problem, which I have already solved, is a very different problem from every other similar question on Stack Overflow. I have posted this question and answer in the hopes that it will help someone else experiencing the same issue (or so that, when I have this problem again in 3 years, I'll find this answer).
I am running VirtualBox 6.1.26 on macOS Catalina 10.15.7. I am emulating centOS 7:
$ uname -r
3.10.0-1160.36.2.el7.x86_64
I "inserted" the VirtualBox Guest Additions CD and followed the auto-run prompts to install the Guest Additions. Part way through, it aborted, saying:
This system is currently not set up to build kernel modules.
Please install the gcc make perl packages from your distribution.
Note that I have gcc, make, perl, kernel-devel, and kernel-headers all installed. It also prompted me to check the file /var/log/vboxadd-setup.log for more details. The contents of that log were interesting:
Building the main Guest Additions 6.1.26 module for kernel 3.10.0-1160.36.2.el7.x86_64.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/3.10.0-1160.36.2.el7.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j4 modules
arch/x86/Makefile:96: stack-protector enabled but compiler support broken
arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended.. Stop.
make: *** [vboxguest] Error 2
modprobe vboxguest failed
Extensive searching for these errors yields multiple forum posts and Stack Overflow questions whose replies and accepted answers reveal either that I'm missing one of those installed packages (I'm not) or that my GCC version is less than 7.3 (when support for CONFIG_RETPOLINE=y was added). However:
$ gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
This is > 7.3, so it does support this feature. I should note that I installed GCC using the Yum devtoolset packages in order to use this newer compiler:
$ sudo yum list installed|grep devtoolset
...
devtoolset-8-gcc.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-c++.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-gdb-plugin.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
...
devtoolset-8-make.x86_64 1:4.2.1-4.el7 #centos-sclo-rh
...
And I do not have any other GCC versions installed:
$ sudo yum list installed|grep gcc
devtoolset-8-gcc.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-c++.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-gdb-plugin.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
libgcc.x86_64 4.8.5-44.el7 #anaconda
And I have this in ~/.bashrc to enable devtoolset upon login:
...
source scl_source enable devtoolset-8
...
What am I doing wrong?
It turned out the problem wasn't that I was using the wrong GCC version (not possible) or that I was missing any installed packages (I wasn't). Instead, it was a consequence of how the VirtualBox Guest Additions "auto-run" works. Something about the way it runs results in a "fresh" environment without devtoolset-8 properly sourced. As a result, it cannot find the installed GCC 8.3.
The solution was simple: When the auto-run prompt appeared, I dismissed it and did not run auto-run. Instead, I opened a fresh Terminal window and changed directories to /run/media/[username]/VBox_GAs_6.1.26 (YMMV on the exact location of the mounted disk), then ran this command:
$ sudo ./VBoxLinuxAdditions.run
That command completed successfully, the kernel module compiled, the Guest Additions installed, and they are working properly now.

How do I build 32-bit binaries with Red Hat Developer Toolset?

I can't find any documentation whatsoever on how to target 32-bit with Red Hat Developer Toolset (version 9.0 in this case running on CentOS 7). The release notes mention:
Generation and manipulation of 32-bit binaries is also supported
It also ships the needed 32-bit libraries in:
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/
However, building fails. Example trying to build a minimal int main() {} program:
$ scl enable devtoolset-9 'g++ -m32 tst.cpp'
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: skipping incompatible /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++_nonshared.a when searching for -lstdc++_nonshared
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: cannot find -lstdc++_nonshared
collect2: error: ld returned 1 exit status
The library it fails to find actually exists though:
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a
No amount of -L flags fixes it (and it would be the wrong solution anyway; the linker should not even be attempting to load 64-bit libraries in -m32 mode.)
What am I missing here?
I guess you didn't notice that /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a is quite likely a dangling symlink:
$ file /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a: broken symbolic link to `../../../i686-redhat-linux/9/libstdc++_nonshared.a'
$
The destination file /opt/rh/devtoolset-9/root/usr/lib/gcc/i686-redhat-linux/9/libstdc++_nonshared.a is however unfortunately not provided by any CentOS package (but it should be in devtoolset-9-libstdc++-devel.i686). Thus it's likely a CentOS-specific packaging mistake as RHEA-2019:4134 provides the questioned package devtoolset-9-libstdc++-devel-9.1.1-2.6.el7.i686.rpm for Red Hat Enterprise Linux 7 including the desired file (explicitly verified by yum install /opt/rh/devtoolset-9/root/usr/lib/gcc/i686-redhat-linux/9/libstdc++_nonshared.a on RHEL 7).

How can I get Ada GNAT gcc 7.3 for Solaris 11?

We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).

Error: No module named 'PyQt5.sip' - When installing eric6-19.03

I have noticed a number of similar questions on stackoverflow, but none that really helped me with my current challenge. I have been attempting to install eric6 on my Raspberry Pi setup. And then I encountered the following messages:
Checking dependencies
Python Version: 3.6.8
PyQt5 could not be detected.
Error: No module named 'PyQt5.sip'
Shall 'PyQt5' be installed using pip? (Y/n) Y
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: PyQt5 in /usr/local/lib/python3.6/site-packages (5.12)
Sorry, please install PyQt5.
Error: No module named 'PyQt5.sip'
And when I attempt to use the pip list to look at what has been installed (as I previously already managed to make and install the PyQt5 from source code):
Package Version
---------- -------
pip 19.0.3
PyQt5 5.12
setuptools 40.6.2
sip 4.19.14
So, how do I overcome the issue that I am currently facing? By the way, I am using the following command when attempting to install eric6:
python3 install.py
Thought you might need to know that if it helps.
Python 3.6 isn't available in any Raspbian distribution, so I assume you installed this yourself. You can't install an out-of-distribution Python version and expect distribution Python packages to work. You have PyQt5 installed, yes, but it's the version of PyQt built for Python 3.5 (I'm assuming you're on Raspbian Stretch).
Sometimes you can install Python libraries with pip, and in theory that could work to install the correct version of PyQt for your version of Python, but PyQt only provides wheels for x86 on PyPI, not for Arm, so PyQt is not pip installable on the Pi. The only way to get PyQt on Raspberry Pi is via apt, where your choices are Jessie (old stable - with Python 3.4), Stretch (current stable - with Python 3.5), and Buster (unstable/testing - with Python 3.7). If there's a need for Python >3.5, your best bet is to try upgrading to Buster, but bear in mind it's not ready for release yet.

Lustre Client on Linux Kernel 4+

Does anyone know if it is possible to install lustre client software on a linux machine that has kernel 4+? From what I have experimented so far, all the working examples are on kernel 3.10. And if I try to install kmod-luster-client on 4+ machine, it fails with:
rpm -ivh kmod-lustre-client-2.10.5-1.el7.x86_64.rpm
error: Failed dependencies:
kernel < 3.10.0-863 is needed by kmod-lustre-client-2.10.5-1.el7.x86_64
kernel(PDE_DATA) = 0x44f0d59d is needed by kmod-lustre-client-2.10.5-1.el7.x86_64
According to lustre/ChangeLog in the b2_10 branch, it works with kernels at least 4.4.133-94.33 (SLES12SP3) and 4.4.0-131 (Ubuntu 16.04).
If you are using a newer kernel, you also need to use a newer version of Lustre. The lustre/ChangeLog on the tip of master (almost 2.12 release) reports support for kernels 4.15.0-32 (Ubuntu 18.04).
It looks like you are trying to install a binary kernel module RPM built for the RHEL7 kernel on a non-RHEL kernel. That is never going to work. You need to either get the right RPMs/Debs for your kernel from https://lustre.org/download/ or download the source and rebuild it for your kernel.
The 2.10.x kernels are currently the LTS maintained releases (bugfixes backported to that release), while 2.11.0 is a feature release that does not have bugfixes backported.