On 6.5, I installed the dependencies mentioned but there is an issue with the openssl ones. There appears to be some dependency misconfiguration going on on the CentOS 6.5 side. Now, Pharo doesn't run out of the box anyway (I guess that what Mariano mentioned is that Pharo runs on CentOS, not that things are running "out of the box with some yum incantations". Well, now, we have the additional openssl problem :-) [root@localhost pharo-vm]# ./pharo ./pharo: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./pharo) [root@localhost pharo-vm]# yum install openssl098e.i686 openssl.i686 Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile * base: mir01.syntis.net * extras: mirror.ate.info * updates: centos.mirror.crcrepairs.com Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package openssl.i686 0:1.0.1e-16.el6_5.4 will be installed --> Processing Dependency: libz.so.1 for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libkrb5.so.3(krb5_3_MIT) for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libkrb5.so.3 for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libk5crypto.so.3(k5crypto_3_MIT) for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libk5crypto.so.3 for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libgssapi_krb5.so.2 for package: openssl-1.0.1e-16.el6_5.4.i686 --> Processing Dependency: libcom_err.so.2 for package: openssl-1.0.1e-16.el6_5.4.i686 ---> Package openssl098e.i686 0:0.9.8e-17.el6.centos.2 will be installed --> Running transaction check ---> Package krb5-libs.i686 0:1.10.3-10.el6_4.6 will be installed --> Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package: krb5-libs-1.10.3-10.el6_4.6.i686 --> Processing Dependency: libkeyutils.so.1 for package: krb5-libs-1.10.3-10.el6_4.6.i686 ---> Package libcom_err.i686 0:1.41.12-18.el6 will be installed ---> Package zlib.i686 0:1.2.3-29.el6 will be installed --> Running transaction check ---> Package keyutils-libs.i686 0:1.4-4.el6 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for openssl which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of openssl of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude openssl.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of openssl installed, but yum can only see an upgrade for one of those arcitectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of openssl installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: openssl-1.0.1e-16.el6_5.4.i686 != openssl-1.0.1e-15.el6.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest On Mon, Mar 3, 2014 at 1:24 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
I do have Pharo running in CentOS 64 bits since a few months already. The way I installed dependencies was:
sudo yum install libX11.i686 libX11-devel.i686 mesa-libGL.i686 mesa-libGL-devel.i686
And then since I was using Zodiac:
sudo yum install openssl098e.i686 openssl.i686 sudo cp /usr/lib/libssl.so.0.9.8e /usr/lib/libssl.so.0.9.8 ldd /opt/pharo/pharoVM/libSqueakSSL.so
On Mon, Mar 3, 2014 at 7:53 AM, <btc@openinworld.com> wrote:
Sergi Reyner wrote:
2014-03-03 9:21 GMT+00:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
A few weeks ago, I wanted to quickly update the pharo in my VPS which runs my IRC bot.
Cent0S 6.5 (and others) cannot use latest VM from get.pharo.org
because of different glibc version.
Fedora, Debian, OpenSuSE, Mint, CentOS, even older Ubuntus... after going throught the list of available distros and installing every one of them, I was left with two choices for setting up Pharo in my VPS: Gentoo and the latest Ubuntu. I did not want to install Ubuntu in the first place because of their policy of "latest of some things, and obsolete versions of something else" which has bitten me time and again. But I did install it, because I had even less interest in maintaning a remote gentoo.
So you have to compile the VM on your own. This is a (probably
incomplete) set of the packages you will need for this task on 64-bit system:
Wouldn´t it be better for everyone to have Pharo compiled against an "older" Glibc, for example, debian´s one, so it can run on more distributions than "latest ubuntu"? From my point of view, asking people to compile their own VMs doesn´t seem to foster usability.
Cheers, Sergi
Would statically linking Linux PharoVM against optimal 32-bit glibc make things easier for users? What would be the file size penalty and are there other issues to consider? File size is less of an issue than it used to be. cheers -ben
-- Mariano http://marianopeck.wordpress.com