[Vm-dev] Can't infer base LD_LIBRARY_PATH

Ben Coman btc at openinworld.com
Sun May 22 14:27:37 UTC 2016


I forgot to mention a roadbump I hit at the start.
     ./envvars.sh: Syntax error: "("

From...
http://forum.world.st/error-with-envvars-sh-when-building-VMMaker-image-td4855076.html
I discovered my /bin/sh  was linked to  /bin/dash
The advice given to change the first line of the script to #!/bin/bash
is a pain since it calls several other scripts, which chain on to
other scripts and all would need to be changed.    I solved it by
re-linking /bin/sh to /bin/bash, but relying on everyone to make such
a global change is not good, nor requiring each VM newcomer to
rediscover this for themselves.

Would it make sense to update the scripts to #!/bin/bash change once
at the download source?

cheers -ben

On Sun, May 22, 2016 at 10:11 PM, Ben Coman <btc at openinworld.com> wrote:
> (btw, Actually I am running ./buildspurtrunkvmmakerimage.sh)
>
> So I found that ./buildspurtrunkvmmakerimage.sh
> creates directory cogspurlinuxht
> containing shell script 'squeak'
> which for LD_LIBRARY_PATH hard codes eight alternative libc locations.
> But after reformatting (see attached) a pattern is apparent such that
> the following generic substitution seems appropriate (and worked for
> me)...
>
> LIBC_SO="`/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed
> 's/^.*=> \([^ ]*\).*/\1/'`"
> LIB=`expr "$LIBC_SO" : '\(.*\)/libc.*'`
> if [ "$LIB" = "" ]; then
>         echo ERROR: Could not determine libc path for VM
>         exit 1
> fi
> SVMLLP="$LIB:/lib:/usr$LIB:/usr/lib"
> LD_LIBRARY_PATH="$PLUGINS:$SVMLLP:${LD_LIBRARY_PATH}" exec $GDB
> "$BIN/squeak" "$@"
>
> except for /lib , /lib32 and /lib64 which substitute as...
> SVMLLP="$LIB:/usr$LIB"
>
> Now I read [1] "The standard paths [/lib and /usr/lib] will still be
> searched, but only after the list of paths in LD_LIBRARY_PATH has been
> exhausted." So I wonder what is the advantage of interleaving the
> standard paths with $LIB ones ?   If /lib and /usr/lib could just be
> left to be "searched anyway" at the end, the the above snippet seems
> to cover all existing cases - and likely new cases without change.
>
> [1] http://wiredrevolution.com/system-administration/how-to-correctly-use-ld_library_path
>
> cheers -ben
>
> On Sun, May 22, 2016 at 2:16 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Ben,
>>
>>    just be sure to post your augmentation of the script back here so the scripts can be updated in svn-soon-to-be-github.
>>
>> On Fri, May 20, 2016 at 8:54 PM, Ben Coman <btc at openinworld.com> wrote:
>>>
>>>
>>> On Sat, May 21, 2016 at 4:44 AM, Clément Bera <bera.clement at gmail.com> wrote:
>>> >
>>> > On Fri, May 20, 2016 at 7:29 PM, Ben Coman <btc at openinworld.com> wrote:
>>> >>
>>> >> I've decided to try and get the simulator working for the first
>>> >> time this weekend.  Its been interesting poking through the VM with
>>> >> gdb, but its not "exactly" fun.
>>> >
>>> >
>>> > Normally if you build a cog development image:
>>> > $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image
>>> > $ cd ./image
>>> > $ ./buildsqueaktrunkvmmakerimage.sh
>>>
>>> I'm sure I've built successfully from there before, but right now I'm
>>> getting and error..
>>>   cogspurlinuxht/squeak trunk50.image UpdateSqueakTrunkImage.st
>>>   Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for
>>> /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak.
>>> Please report your edit to squeak vm-dev.
>>>
>>>   cogspurlinuxht/squeak SpurVMMaker.image BuildSqueakSpurTrunkVMMakerImage.st
>>>   Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for
>>> /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak.
>>> Please report your edit to squeak vm-dev.
>>>
>>> I'm in the process of tracking that down, but just reporting in case
>>> there is a known quick fix.  btw, I'm on Debian Jessie
>>> Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt20-1+deb8u3
>>> (2016-01-17) i686 GNU/Linux
>>>
>>> cheers -ben
>>>
>>> >
>>> > You have multiple scripts available with comments to run the simulator that work out of the box. It should take a couple minutes to get it working. Then the easiest is to simulate a REPL image to easily debug what you want.
>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>


More information about the Vm-dev mailing list