[Pharo-project] Problem with Arch Linux and Cog
Robert Sirois
Schwab,Wilhelm K
The next step would be strace, which might reveal the vm's thoughts. Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :) Once you get the output, it will be verbose, but grep is your friend in that case. You probably know this, something like
cat strace-log.txt | grep uuid
could be revealing. It might show where Cog thinks the library lives. It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going. I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer.
If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around. If the library is not on the machine, that might be the problem.
HTH.
Bill
Sent: Tuesday, January 10, 2012 10:20 PM
To: pharo-...@lists.gforge.inria.fr
Subject: [Pharo-project] Problem with Arch Linux and Cog
Milan Mimica
Stéphane Ducasse
On Jan 11, 2012, at 12:25 PM, Milan Mimica wrote:
> This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you.
> I could do the Slackware package.
excellent
what we should do is that the package is automatically created using jenkins.
laurent laffont
Laurent
Alexander Lazarević
>
> The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable.
Sure! Please note that Ian Piumarta, the maintainer of the original
(stack) VM for unix did provide packages for RedHat and Debian systems
early on. There are still packages for the latest VM for RedHat/Suse?
on [1].
I think Matej Kosik, José Luis Redrejo and others took the labor of
building a license clean squeak-vm packages, which got accepted by
Debian [3] and Ubuntu [4]. I'm not sure about their current status and
do not know about other distributions.
I don't think that projects like the linux kernel, gnome or whatever
all build packages for every linux distribution that's out there. It's
true that there is a different demand after the linux kernel than
after the squeak-vm. But we still have limited resources and can only
hope that squeak/pharo/cuis keeps attracting people, so that they get
included in some distributions.
The cog VM might be the standard VM inside the pharo/cuis/squeak
communities, but it's still experimental and only for x86. So there is
the question how to integrate the cog vm/stack vm both into eg. the
debian distribution that is also targeting amd64, mips, mipsel,
powerpc, s390, s390x, sh4. You can't just provide a new squeak-vm
package that contains the latest cog vm.
Alex
[1] http://www.squeakvm.org/unix/
[2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-March/126624.html
[3] http://packages.debian.org/de/sid/squeak-vm
[4] http://packages.ubuntu.com/hardy/squeak-vm
Robert Sirois
From: bsc...@anest.ufl.edu
To: Pharo-...@lists.gforge.inria.fr
Date: Wed, 11 Jan 2012 03:47:05 +0000
Subject: Re: [Pharo-project] Problem with Arch Linux and Cog
Schwab,Wilhelm K
I didn't want to presume to tutor you on what might be basics to you. With lots of "jumping in at the deep end" and no small amount of help from people like Nick, I've come a long way in my understanding of Linux, but I'm still not a master of the art. If something I said is unclear, feel free to ask.
(1) Partial answer: I am still using 1.1.1 for most work; it runs happily on Ian's VM (http://squeakvm.org/unix/). It's worth a try.
(2) that's a very good question. The answer is probably no, but I'd be happy to be shown wrong. I like Ubuntu, but they offer either chaos (six month releases) or near stagnation (the LTS releases). Something in between would be nice. A few years ago, I met some very enthusiastic Mandriva users. On Ubuntu, a compromise is to use an LTS release and alternate repositories; I recently brought my R installation forward a couple of years using one. I am not at all happy about Unity/Gnome-3 changes that are brewing, so I am looking for good alternatives.
Re your current situation, I do not argue with those saying that binaries on Linux can be a poor mix. I do, however, think that library search paths are a VERY likely explanation for your troubles. Certainly, it should be ruled out as a cause, and the complete absence of related diagnostic information is a red flag. Silent failures have been a fact of life on Squeak from the early days, and I have never understood why it has been tolerated; we all suffer from it. Sig's plan to move the search logic into the image would be a huge boost, because we could both adapt it as needed, and (more importantly) see what is happening w/o the need for external tools.
Give strace a try. *IF* the UUID library is being sought in all the wrong places, a symlink **might** get you going. I say that because I just went through the exercise on Ubuntu. Let me know if I can help sort out how to use the tools in question. Apologies in advance for any time you waste following my advice; but, at a minimum, exploring the failure would give you experience with tools that will be helpful "next time."
Bill
To: pharo-...@lists.gforge.inria.fr