'no version information available' warning when starting pypy on centos6 - centos

I've been struggling with this for a few hours and not sure how to get rid of it(or if it'll cause any problems for me) but I keep getting the following warnings when I start pypy on centos6:
[root#domU-123 bin]# ./pypy
./pypy: /usr/lib64/libssl.so.0.9.8: no version information available (required by ./pypy)
./pypy: /usr/lib64/libcrypto.so.0.9.8: no version information available (required by ./pypy)
Python 2.7.2 (0e28b379d8b3, Feb 09 2012, 19:41:03)
[PyPy 1.8.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``"Let's go." - "We can't" - "Why
not?" - "We're waiting for a Translation." - (despairingly) "Ah!"''
>>>>
Here's a copy of my install script(I install this on a fresh centos system):
#install pypy
wget https://bitbucket.org/pypy/pypy/downloads/pypy-1.8-linux64.tar.bz2
tar xvf pypy*
yum -y install openssl098e
ln -s /usr/lib64/libssl.so.0.9.8e /usr/lib64/libssl.so.0.9.8
ln -s /usr/lib64/libcrypto.so.0.9.8e /usr/lib64/libcrypto.so.0.9.8
ln -s /lib64/libbz2.so.1.0.4 /lib64/libbz2.so.1.0
Can anyone suggest how to fix it? Am I missing a package or does something need to be configured?

this is the dreaded binary compatibility problem with linux
basically if you don’t have the same distro/version as the build server,
you can assume it may break due to distro policies wrt libs
for recent builds, its likely broken on anything that’s not similar
to whats on the build server (which runs a recent ubuntu)
(before it was a debian, but that broke openssl in strange ways on a regular basis)
since distros seem break general binary compatibility on regular basis,
this is not something that the pypy core team will spend more time on
external maintainers wanted

Related

dpkg: why does instdir need admindir parameter on Mint 21

We create a Debian package of our application using CPack which can be installed on Linux Mint 19 like this:
$ sudo dpkg -i --instdir=/opt myapp.deb
With Linux Mint 21 the (installed) dependencies are not resolved:
dpkg: dependency problems prevent configuration of myapp:
myapp depends on libsqlite3-0 however:
Package libsqlite3-0 is not installed.
...
After reading the dpkg man page I set the admindir parameter and the installation succeeds:
$ sudo dpkg -i --instdir=/opt --admindir=/var/lib/dpkg/ myapp.deb
If I do not set admindir to /var/lib/dpkg/ then the right environment is not found. Why is that? And why did it work without admindir on Mint 19? Using parameter root does not help because it expects the administrative directory to be a subdirectory of the instdir.
This is a bug, which seems I introduced in dpkg 1.21.0. I'll be preparing a fix and regression tests for dpkg 1.21.10 which should hit Debian unstable in few days I guess. For Mint, which seems to be based on Ubuntu, you'd need to request the Ubuntu people to consider including that fix once it's in Debian unstable, and then the Mint people to do the same. Otherwise you can specify both options as a workaround for now. :/
Please feel free to report this kind of problems upstream in the bug tracking system next time, I just happened to see this by accident today. :)

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.

yum command : python version mismatch

I have Red Hat Linux (Red Hat Enterprise Linux Server release 6.5 (Santiago) ) and yum in not working with message
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
No module named yum
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.7.8 (default, Nov 7 2014, 11:45:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
Current version of python is 2.7.8
Any help is appreciated.
CentOS 6 ships with python 2.6. Someone installed an incompatible version of python system-wide and that has broken things. That should not have been done.
You need to find out how the 2.7 version of python was installed and fix that (by removing the incorrect package or by removing the source-installed python or by fixing the $PATH or whatever else is appropriate).
To help figure out what the problem is exactly we need the output from the following commands (as a start).
What does rpm -qa python\* say?
What does which -a python say?

Error setting up a virtualenv with jython 2.7b3

I'm trying to set up a virtual environment using jython 2.7b3. I'm running Mac OS 10.8.5 in case that's relevant.
I installed virtualenv (1.11.6) using jython and easy_install as recommended here: http://www.jython.org/jythonbook/en/1.0/appendixA.html
But when I run:
$ /usr/local/jython/jython2.7b3/bin/virtualenv jython-venv
I get the output:
Cannot find file /usr/local/jython/jython2.7b3/Include (bad symlink)
New jython executable in jython-venv/bin/jython
ERROR: The executable jython-venv/bin/jython is not functioning
ERROR: It thinks sys.prefix is u'/usr/local/jython/jython2.7b3' (should be u'/..../jython-venv')
ERROR: virtualenv is not compatible with this system or executable
(Where /..../jython-venv stands for the path to the new virtual environment I created.)
When I run jython-venv/bin/jython I get a normal jython prompt:
$ jython-venv/bin/jython
Jython 2.7b3 (default:e81256215fb0, Aug 4 2014, 02:39:51)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_51
Type "help", "copyright", "credits" or "license" for more information.
>>>
What am I missing? Why does virtualenv think the executable doesn't work, even though it seems to be functioning OK by itself? Is it just a matter of telling it the correct sys.prefix? If so how can I do that?
Many thanks in advance for your help...
Found the problem and solution described here:
http://seletz.github.io/blog/2012/04/06/jython-classpath-virtualenv/
Apparently there is a bug in virtualenv that causes this issue when JYTHON_HOME is set, which was my problem.
As soon as it's unset with unset JYTHON_HOME, virtualenv works (almost) as expected.
$ echo $JYTHON_HOME
/usr/local/jython/jython2.7b3
$ unset JYTHON_HOME
$ echo $JYTHON_HOME
I say "almost" as expected because it still had an issue installing pip. Luckily that problem and its solution described here: https://gist.github.com/skyl/ea2ab1c62a547e381411

Why can't I install DBD::mysql so I can use it with Maatkit?

I'm trying to install Maatkit following the maatkit instructions. I can't get past having to install DBD::mysql. "Warning: prerequisite DBD::mysql 1 not found."
When I try to install DBD::mysql from cpan, I get very helpful "make had returned bad status, install seems impossible".
Perl is "v5.8.8 built for darwin-thread-multi-2level", the one that came with OS X. I also tried building from source with same result.
We need more of the error message. Most likely, you are missing the MySQL client development files. I don't know how to install these on OSX. Also see this older post on OSX 10.5.2 , in which some other failures with the mysql client libraries are found.
Possibly post this question with more parts of your error message at perlmonks.org, if stackoverflow doesn't allow for convenient pasting of your make session or rather the last 20 or 10 lines of it.
Some more Googling with site:perlmonks.org also finds this post which has some more details on things to watch out for when installing DBD::MySQL. Depending on how comfortable you feel with the installation, you might want to manually run the tests, supplying a test database and test user or even skip testing the module.
After a bit more googling, this worked for me:
sudo ln -s /usr/local/mysql/lib /usr/local/mysql/lib/mysql
sudo ln -s /usr/local/mysql/include /usr/local/mysql/include/mysql
sudo perl -MCPAN -e 'install Bundle::DBD::mysql'
press enter a bunch of times, then in your maatkit folder:
perl Makefile.PL
sudo make install
and you'll find the mk-* programs in /usr/local/bin/
You will want to install MySQL first. I usually use the binary packages they provide for OS X. The packages do include the headers and MySQL client libraries which DBD::MySQL requires. Once the MySQL package is installed, DBD::MySQL should install without issue.
Here is my output:
$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite DBD::mysql 1 not found.
Writing Makefile for maatkit
$ mysql --version
mysql Ver 14.12 Distrib 5.0.51b, for apple-darwin9.0.0b5 (i686) using readline 5.0
I notice that there are in effect DBD::MySQL packages in the fink repositories. For example:
ayaz#ayazs-macbook$ fink list | grep -i 'dbd-mysql'
dbd-mysql-pm586 3.0008-10 Perl5 Database Interface to MySQL
dbd-mysql-pm588 3.0008-10 Perl5 Database Interface to MySQL
Perhaps installing through fink one of those packages may help alleviate your troubles.
Also, and I cannot be certain of this, you may want to install for MySQL-5.x (if you have that version installed) the mysql15-dev and mysql15-shlibs packages. I installed those through fink thus:
$ sudo fink --use-binary-dist install mysql15-dev