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 <[email protected]
> 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, <[email protected]> wrote:
>
>> Sergi Reyner wrote:
>>
>> 2014-03-03 9:21 GMT+00:00 Pavel Krivanek <[email protected]>:
>>
>> 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
>
