RS, 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 ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Robert Sirois [watchlala@hotmail.com] Sent: Thursday, January 12, 2012 10:11 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Problem with Arch Linux and Cog Thanks for the response (everyone). Wilhelm, I appreciate your confidence in my skills as a programmer ;) but this type of debugging is a little beyond me. I may take this information and have someone locally help me out if possible. In the meantime, I have two other questions: 1) Is Pharo still deployable on Squeak. I guess for some reason I assumed it was only deployable with a Cog vm now, perhaps I misled myself? and 2) Are there any distributions of Linux that are true and tested, so to speak, with Pharo/Cog? Thanks! RS ________________________________ From: bschwab@anest.ufl.edu To: Pharo-project@lists.gforge.inria.fr Date: Wed, 11 Jan 2012 03:47:05 +0000 Subject: Re: [Pharo-project] Problem with Arch Linux and Cog You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output. 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 ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Robert Sirois [watchlala@hotmail.com] Sent: Tuesday, January 10, 2012 10:20 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Problem with Arch Linux and Cog I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well. Was there any solution, or is the solution to not use Arch Linux? Related to this thread: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.h... http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.h... Thanks, RS

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.

PS. I do love on-click paradigm. Too bad it doesn't work.

On 11 January 2012 04:20, Robert Sirois <watchlala@hotmail.com> wrote: I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.h... http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.h...

Thanks, RS

-- Milan Mimica http://sparklet.sf.net

2012/1/11 Milan Mimica <milan.mimica@gmail.com>

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.htm... [3] http://packages.debian.org/de/sid/squeak-vm [4] http://packages.ubuntu.com/hardy/squeak-vm