well... real solution is to compile your own VM. 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. Esteban On Aug 28, 2013, at 12:41 PM, Jan Vrany <jan.vrany@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.htm...
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