bblochl at arcor.de
Sat Nov 6 09:47:46 CET 2010
There is a SqueakVM for 64 bit as well, see:
As squeak is running on my machine with fedora13 64 bit WITHOUT the 32
bit libGLU.so.1 (as I have explained in another mail, the only libGLU is
in the directory /usr/lib64) one can make sure that there is a 64 bit
version running (and offered in the fedora13 64 bit repository, from
where I have installed). Vice verse, on my 64 bit debian lenny
installation squeak does not run. On that system as (nearly) only the
32 bit libs installed. (I will analyse that case if I find some time.)
There seems to be a situation of shift to 64 bit with some library
breaks in different systems.
Indeed it is possible to install the 32 bit libs with apt-get on debian
like machines and yum or rpm or other tools on other linux brands. That
would not help so much because it does not solve he incompatibility of
my installed 64 bit SqueakVM running on my machine with the 32 bit
pharo-image. (I have not yet tried, but in this logic I would have to
install a 32 bit squeak as well.)
The file vm-display-X11 of my actual squeak version is in directory
/usr/lib64/squeak/3.10-5. I tried to change pharo.sh to point
explicitely to that directory to use that vm. The result:
~ Pharo-1.1-OneClick.app$ ./pharo2.sh
libGLU.so.1: wrong ELF class: ELFCLASS64
could not find display driver vm-display-X11; either:
- check that /usr/local/lib/squeak/4.0.3-2202/vm-display-X11.so exists, or
- use the '-plugins <path>' option to tell me where it is, or
- remove DISPLAY from your environment.
Abgebrochen (Speicherabzug geschrieben)
As you can see pharo is looking for the vm of squeak version 4.0.3-2202
instead of 3.10-5. I do not know where to change this path in pharo and
if it makes sense? I do not understand, that there are so.*-versions in
In my oppinion the clean and save solution for the future is to provide
an additional 64 bit pharo-image beside the 32 bit version.
Am 05.11.2010 22:57, schrieb Mariano Martinez Peck:
> Yes, usually, since SqueakVM is 32 bits, on a 64 bits OS, you need to
> install the 32bits OS libraries.
> For example, in Ubuntu, I remember doing: "*sudo* *apt*-*get* install
> On Fri, Nov 5, 2010 at 6:32 PM, bb <bblochl at arcor.de> wrote:
>> Am 05.11.2010 10:31, schrieb bb:
>>> Am 05.11.2010 10:09, schrieb bb:
>>>> I tried to proceed as described on
>>>> http://pharo-project.org/community/issue-tracking and tried to search
>>>> the mailing list in the archive. But in trying to access the archive I
>>>> get the message from Nabble(?):
>>>> This node has been deleted
>>>> Here a problem description:
>>>> I installed Pharo latest version on debian lenny 64 bit and it works
>>>> properly from start on, but I had/have some problems with Squeak.
>>>> I installed Pharo (same procedure as above) on red hat 64 bit Kernel
>>>> 18.104.22.168-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it
>>>> does not work, but Squeak works properly. The message is:
>>>> [bb at localhost Pharo-1.1-OneClick.app]$ ./pharo.sh
>>>> libGLU.so.1: cannot open shared object file: No such file or directory
>>>> could not find module vm-display-X11
>>>> Abgebrochen (Speicherabzug geschrieben)
>>>> [bb at localhost Pharo-1.1-OneClick.app]
>>>> I installed repeatedly and tried to use available VM's from Squeak and
>>>> also tried some other "tricks", i.e copy all Pharo-files in the same
>>>> directory ...
>>>> May be someone else has some experience with Pharon on red hat?
>>>> Please tell me if it is worth to make a ticket?
>>>> Regards BB
>>> Appendix: The libGLU runtime library + development package are
>>> installed. I will check if there is something on error with that
>>> packages on fedora/red hat.
>>> May be someone else has some extended expirence with this issue?
>>> Tegards BB
>> Thanks for the correct link for bug-reporting!
>> Thanks for many helping contributions and help to that topic!
>> At least I found a striking explanation and I think the developers of
>> Pharo might take care of:
>> The libGLU-files on fedora13 are not in the directory /usr/lib but in
>> /usr/lib64. I cross-checked debian lenny and found that libs in
>> /usr/lib. (lenny does have a directory usr/lib64 as well.)
>> I had to deal with such differences of different Linux brands and while
>> moving to 64 bit very often in the past.
>> I am not a Pharo-developer, but I recommend to check the pathes set and
>> eventually extend the settings with the 64-bit alternatives.
>> An alternative might be a hard link?
>> ~$ ln /usr/lib64/libGLU.so.1 /usr/lib/libGLU.so.1
>> But now I ave another error message:
>> ~ Pharo-1.1-OneClick.app]$ ./pharo.sh
>> libGLU.so.1: wrong ELF class: ELFCLASS64
>> could not find module vm-display-X11
>> Abgebrochen (Speicherabzug geschrieben)
>> I am not allmighty and more or less just a hobbyist with just an
>> underdeveloped CS knowledge, but I think that there is a trial to link a
>> 32 bit Pharo with an object-file (libGLU.so.1) which was compiled for 64
>> bit? (May be that debian still delivers a 32 bit object file, so it
>> One might try to recompile with the '-m64' flag of gcc. May be a
>> compilerrun with correct autoconf (configure) scripts, set to CC="gcc
>> -m64" (or CC="gcc -m32") might help?
>> So I would say, the problem is fixed but not solved.
>> Regards BB
More information about the Pharo-project