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.vr...@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.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. >>> >>> 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.
