[Vm-dev] Can't infer base LD_LIBRARY_PATH

[gettimothy]

This may be relevant if you are on a 64 bit Ubuntu machine ..

IIRC 64 bit Ubuntu puts its 32 bit libs in /usr/lib32  (its 64 bit libs are in /usr/lib)


Slackware 64 reverses the Ubuntu convention and puts its 32 bit libs in /usr/lib and the 64 bit libs in /usr/lib64


hth

tty






---- On Sun, 22 May 2016 10:11:53 -0400 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 
> 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160522/52984d85/attachment.htm