[Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

Igor Stasenko siguctua at gmail.com
Wed Aug 28 08:03:09 EDT 2013


There is another option (or call it workaround, if you like):
 Just find a years old VM which works on your years old platform and be
happy..
(but don't expect , of course, that latest Pharo image will be compatible
with it)


On 28 August 2013 13:29, Jan Vrany <jan.vrany at fit.cvut.cz> wrote:

> On 28/08/13 11:58, Esteban Lorenzano wrote:
>
>> well... real solution is to compile your own VM.
>>
>
> Really? Then why do you at all offer VMs to download if people are
> requested to compile at their own? :-) What would you say if you would
> have to compile JVM on every system you use just because the pre-built
> binaries are compiled against most recent libs? This maybe works in
> academia but not in real world. Sorry, I don't take it.
> That's not 'a real solution', this is merely a workaround.
>
>
>
>  we can offer support (but should be pretty straight forward, specially in
>> linux systems).
>>
>> I disagree with the solution proposed in (2), the cost of maintaining
>> such approach would be exponential.
>>
>
> No, not really. There aren't many of those (at least, weren't in my case)
> and I found out that sometimes I could do better (faster) job :-)
>
> Alternatively, you can just compile on old-enough system and hope that it
> will work.
>
> If you have another solution to this particular problem, please
> share. I would love to know it!
>
> Anyway, that's what I did and what helped in my case. That's all I'd
> like to say.
>
>
> Best, Jan
>
>
>
>>   Esteban
>>
>> On Aug 28, 2013, at 12:41 PM, Jan Vrany <jan.vrany at fit.cvut.cz> wrote:
>>
>>  Hi,
>>>
>>> we had similar problems. After a bit of a research, I concluded that
>>> there are basically two options for this sort of GLIBC a problem:
>>>
>>> 1) Workaround: recompile the VM on the target system, i.e., on
>>>    Ubuntu 8.04
>>>
>>> 2) Solution: find symbols that introduces that dependency and then
>>>    simply not use them in the VM code. This means that you may have
>>>    to provide your own implementation of certain C functions
>>>    (memset, stat, things like that)
>>>
>>>    To do so, nm and objdump is your friend.
>>>
>>> If I were you, I would go for a workaround.
>>>
>>> Best, Jan
>>>
>>>
>>> On 28/08/13 11:25, Sven Van Caekenberghe wrote:
>>>
>>>> Hi,
>>>>
>>>> I asked this question before
>>>>
>>>>    http://forum.world.st/Pharo-**dev-Latest-vm-on-Ubuntu-8-04-**
>>>> 4-LTS-tt4689467.html<http://forum.world.st/Pharo-dev-Latest-vm-on-Ubuntu-8-04-4-LTS-tt4689467.html>
>>>>
>>>> and yes I know that Ubuntu 8.04 is old, but I am really stuck.
>>>>
>>>> I need to deploy a Pharo #20619 image and I need a VM that works on
>>>> Ubuntu 8.04 _and_ that is not 'too old' (like Eliot's most recent CogVM
>>>> where I am getting lots of NB errors as well).
>>>>
>>>> The problem seems to be the dependency on the glibc 2.11.
>>>>
>>>> Has anyone successfully solved this issue ?
>>>>
>>>> Thx,
>>>>
>>>> Sven
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130828/f8dd88a2/attachment-0002.html>


More information about the Pharo-dev mailing list