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
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine. On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven@stfx.eu> 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
On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni@gmail.com> wrote:
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine.
I've never done that, but it should be doable on Linux I guess. Where/how do I start ?
On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven@stfx.eu> 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
https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD and of course, you can ask as many questions as you want :) Esteban On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni@gmail.com> wrote:
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine.
I've never done that, but it should be doable on Linux I guess. Where/how do I start ?
On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven@stfx.eu> 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
oops, the newImage.sh is most probably outdated :) On Aug 28, 2013, at 12:59 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD
and of course, you can ask as many questions as you want :)
Esteban
On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni@gmail.com> wrote:
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine.
I've never done that, but it should be doable on Linux I guess. Where/how do I start ?
On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven@stfx.eu> 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
On 28 Aug 2013, at 12:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
https://github.com/pharo-project/pharovm/blob/master/HOWTOBUILD
and of course, you can ask as many questions as you want :)
I will have to reconsider: too many tools are too old (git, cmake, who knows what else). Unless someone else has already done it and can give me an executable, I will have to find another solution and abandon that machine for pharo.
Esteban
On Aug 28, 2013, at 12:56 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni@gmail.com> wrote:
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine.
I've never done that, but it should be doable on Linux I guess. Where/how do I start ?
On 2013-08-28, at 12:25, Sven Van Caekenberghe <sven@stfx.eu> 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
On 2013-08-28, at 12:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 12:40, Camillo Bruni <camillobruni@gmail.com> wrote:
If you're in for DIY, you can "simply" compile the current VM under 8.04 and you should be fine.
I've never done that, but it should be doable on Linux I guess. Where/how do I start ?
You can check our VM builds https://ci.inria.fr/pharo/view/VM/job/PharoVM/configure basically you will have to run the bash script there an check that all the necessary libs are installed, for which you will find a script here: https://gitorious.org/pharo-build/pharo-build/source/9fe0d031d4b8d45d464c02c... I hope that get's you started
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
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
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@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
for older systems, you are by your own. Is like that, yes. We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old. Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources. So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions. On Aug 28, 2013, at 1:29 PM, Jan Vrany <jan.vrany@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 :-)
you are invited to provide your working version, it would be cool for everybody :)
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@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
On 28/08/13 12:54, Esteban Lorenzano wrote:
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system. To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution". I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-) Best, Jan
Am 28.08.2013 um 14:19 schrieb Jan Vrany <jan.vrany@fit.cvut.cz>:
On 28/08/13 12:54, Esteban Lorenzano wrote:
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
Indeed, I don't even understand what is your point. You are arguing that offering binaries for download is pointless if it does not support a wide range of systems. So is there even a way to compile a single binary for at least every version of a linux distro over the last couple of ears? I so then name it and there are guys who will be lucky incorporating your strategy. Arguing against the need of compilation is somewhat I cannot understand either. Of course every binary has to be compiled for every different system. The part that does make it work is the distro as a dependency tree of packages and versions. So Damien created this nice launchpad ppa archive that enables compiling the vm for a lot of ubuntus up to 10.04 which is over 3 years old. For everything else you are in bad luck. This community cannot deliver everything someone things is needed to be a mature system. We tried already to add the vm to the debian channels but it wasn't possible. And even then it would only be for debian. So to solve this particular problem you could go to [1], open a project for the pharo-vm and maintain easily the builds for a wide variety of linux systems. Problem solved, everyone is thankful. Complaining doesn't solve anything. Norbert [1] https://build.opensuse.org/
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
On Aug 28, 2013, at 2:19 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 28/08/13 12:54, Esteban Lorenzano wrote:
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
On Aug 28, 2013, at 3:36 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
This quote is related to FireFox and Apple, but it's the same idea: âApple releases new versions of its operating systems relatively quickly, and each new version contains significant changes that we must adapt to,â Aas said. âThis requires resources, and with limited resources this sometimes means we have to make tough decisions about where to invest.â http://www.macworld.com/article/1168241/mozilla_sets_end_of_firefox_for_os_x... Mozilla had "limited" resources (revenue, but revenue is resource in software) of over 163 million USD in 2011⦠Marcus
On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
I know our resources are limited, but some arguments in this discussion are just wrong. It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008) On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO. And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work. But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating.
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
just because I have vocation of service :) enjoy, Esteban On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
I know our resources are limited, but some arguments in this discussion are just wrong.
It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008)
On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO.
And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work.
But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating.
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
On 28 Aug 2013, at 17:41, Esteban Lorenzano <estebanlm@gmail.com> wrote:
just because I have vocation of service :)
<pharovm-u804.tar.gz>
Fantastic ! It works perfectly well on my old Ubuntu 8.04. I assume from the build date that you compiled this today, especially for me - I will have to buy you a nice beer or two next time we meet. Thanks again, Sven PS: lets keep this vm around for future use
enjoy, Esteban
On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
I know our resources are limited, but some arguments in this discussion are just wrong.
It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008)
On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO.
And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work.
But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating.
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
On 2013-08-28, at 21:37, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 17:41, Esteban Lorenzano <estebanlm@gmail.com> wrote:
just because I have vocation of service :)
<pharovm-u804.tar.gz>
Fantastic !
It works perfectly well on my old Ubuntu 8.04.
I assume from the build date that you compiled this today, especially for me - I will have to buy you a nice beer or two next time we meet.
Thanks again,
Sven
PS: lets keep this vm around for future use
already done: http://files.pharo.org/vm/pharo/linux/ as advised by esteban ;)
On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed I do not see how we could provide support that oracle does not. We should be realistic.
I know our resources are limited, but some arguments in this discussion are just wrong.
It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008)
yes, is possible that it runs. But basically what they say is that if it doesn't, you are by your own, they will not provide support (and I was talking about support). And they are oracle, that's my point: they dropped support for ubuntu 8 a couple of years ago...
On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO.
And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work.
well... yes and no... pharo3 will require pharo3vm, but pharo2 can be run with VMs from more than a year (the real problem here was the annoying SmallInteger bug, and probably some other minor VM problems)
But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating.
for older systems, you are by your own. Is like that, yes.
We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html (latest is 10.04... which we support, or intent to at least) Also... we are not oracle, we have more limited resources.
So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
This is not the only instance of the problem. If I'm not much mistaken, same problem has been recently reported for Debian 7 (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
in that moment answer was: compile it yourself until we provide a working version (which we now provide). Ubuntu 8 is another problem :( but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
To make me clear, I have no problem if you say "Sorry, we don't support anything older than 12 months. Or 3 years. Or ...". I just don't think that asking people to recompile whenever there is glibc dependency problem is "real solution".
I'm very sorry for starting this pointless discussion.
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 :-)
you are invited to provide your working version, it would be cool for everybody :)
Unfortunately, I've done it for a different VM :-)
Best, Jan
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@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@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.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
-- Best regards, Igor Stasenko.
On 28 Aug 2013, at 14:03, Igor Stasenko <siguctua@gmail.com> wrote:
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)
Hmm, that is not really true: recent images have certain requirements (native boost, file/time primitives, â¦) - catch 22
On 28 August 2013 13:29, Jan Vrany <jan.vrany@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@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
-- Best regards, Igor Stasenko.
On 28 Aug 2013, at 12:41, 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.
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.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
participants (8)
-
Camillo Bruni -
Esteban Lorenzano -
Igor Stasenko -
Jan Vrany -
Marcus Denker -
Norbert Hartl -
Stéphane Ducasse -
Sven Van Caekenberghe