On 28 Aug 2013, at 12:41, Jan Vrany <jan.vr...@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.
Thanks for the suggestion. I was also thinking if it would be possible to somehow compile a new glibc in a local directory and use it. Was it easy to compile a pharo VM ? > 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 >> >> 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 >> > >
