Linux vm default plugins directory
Locked
Linux vm default plugins directory
 
|
A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. FWIW, without a -plugins option, this is what happens with the current sources: Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-OSS Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-MacOSX Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-Sun Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-pulse Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-ALSA Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.MiscPrimitivePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FilePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SecurityPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LargeIntegers Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.BitBltPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.B2DPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LocalePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SocketPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FloatArrayPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.Matrix2x3Plugin Note the extra / in the paths. Some of the plugins should fail to load; the point is that *all* of them fail to load. Bill |
Re: Linux vm default plugins directory
|
|
Hi Wilhelm, On Wed, Sep 1, 2010 at 12:01 PM, Schwab,Wilhelm K <[hidden email]> wrote:
Set LD_LIBRARY_PATH to include the relevant directory. Here's the script I use at Teleplace, where the script is root/bin/squeak and the so's are in root/lib/squeak/3.9-7. You can tailor to suit.
#!/bin/sh BIN=`/usr/bin/dirname "$0"`/../lib/squeak/3.9-7 # At least on linux LD_LIBRARY_PATH's components must be absolute path names case "$BIN" in
/*) PLUGINS="$BIN";; *) PLUGINS="`pwd`/$BIN" esac # prepending is less flexible but safer because it ensures we find the plugins # in the same directory as the VM.
LD_LIBRARY_PATH=$PLUGINS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} exec "$BIN/squeak" "$@" HTH Eliot
|
Re: Linux vm default plugins directory
|
|
On 01.09.2010, at 21:12, Eliot Miranda wrote: > Hi Wilhelm, > > On Wed, Sep 1, 2010 at 12:01 PM, Schwab,Wilhelm K <[hidden email]> wrote: > >> A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. >> > Set LD_LIBRARY_PATH to include the relevant directory. Here's the script I use at Teleplace The current "squeak" script fills in the plugins path, so there is no need to fiddle with LD_LIBRARY_PATH. http://squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/squeak.in However, I occasionally too see a plugin that inexplicably does not want to load. - Bert - |
RE: Linux vm default plugins directory
|
|
In reply to this post by Schwab,Wilhelm K
Bert, Eliot, FWIW, I have had terrible results with LD_LIBRARY_PATH on Ubuntu - maybe I'm just missing something. I probably should let the squeak script handle it, but it seems silly to use a script to call a script, so I've typically gone straight to the vm; that appears to be getting harder to do with time. About plugins not loading, my big point is that we should not have to guess about what is or is not happening. The vm does not provide enough information to reliably fix problems. Bill On 01.09.2010, at 21:12, Eliot Miranda wrote: > Hi Wilhelm, > > On Wed, Sep 1, 2010 at 12:01 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > >> A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. >> > Set LD_LIBRARY_PATH to include the relevant directory. Here's the script I use at Teleplace The current "squeak" script fills in the plugins path, so there is no need to fiddle with LD_LIBRARY_PATH. http://squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/squeak.in However, I occasionally too see a plugin that inexplicably does not want to load. - Bert - |
Re: Linux vm default plugins directory
|
|
In reply to this post by Bert Freudenberg
On Wed, Sep 1, 2010 at 12:22 PM, Bert Freudenberg <[hidden email]> wrote:
If one has a plugin that depends on a secondary library then fiddling with LD_LIBRARY_PATH can be necessary.
Inexplicably, or because some symbol is undefined? cheers Eliot
|
Re: Linux vm default plugins directory
|
|
On 01.09.2010, at 22:38, Eliot Miranda wrote:
True, but that's not specific to squeak :)
Inexplicably. I'm pretty certain that I've seen a plugin I just compiled fail, and when compiled again it worked. - Bert - |
Re: Linux vm default plugins directory
|
|
On Wed, Sep 1, 2010 at 1:53 PM, Bert Freudenberg <[hidden email]> wrote:
Linux creeps me out like this. Th way it does so currently is when using gdb and one is not supposed to have to exit if one recompiles teh executable one is debugging, except when one does because every one out of four times it just doesn't work. Not debugging the program one thinks one is debugging is only slightly less well known than getting mired in a land war in Asia and yet gdb on linux invades Afghanistan regularly...
|
Re: Linux vm default plugins directory
|
|
In reply to this post by Bert Freudenberg
On Wed, Sep 1, 2010 at 1:53 PM, Bert Freudenberg <[hidden email]> wrote:
Right. But -plugins only solves the issue one level deep whereas fiddling with LD_LIBRARY_PATH, as horribly ugly as that is, solves it for any depth, hence in my book its the only way to go.
cheers Eliot |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |