[Vm-dev] RE: [Pharo-project] CogVM driver vs executable

Tue Jan 31 22:30:21 UTC 2012

On Tue, Jan 31, 2012 at 2:21 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu>wrote:

>
>  Eliot,
>
> You are correct about the name mangling, but that's a second level. With
> all due respect, Cog starts the search in the wrong place. I hope we can
> sort it out.
>

I didn't write the search machinery.  So what does it do and what should it
do, IYO?

>
> If the rock and the hard place keep coming after us, maybe we need in
> in-image (where it can be readily seen and modified) registry of names.
> The current approach is not working (I know you've worked hard, but more is
> needed).
>
> Sounds like I need to start reading vm-dev - will do.
>
> Bill
>
>
>
>   ------------------------------
> *From:* pharo-project-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Eliot Miranda [
> eliot.miranda at gmail.com]
> *Sent:* Tuesday, January 31, 2012 3:06 PM
> *To:* Pharo-project at lists.gforge.inria.fr
> *Cc:* Squeak Virtual Machine Development Discussion
> *Subject:* Re: [Pharo-project] CogVM driver vs executable
>
>
>
> On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K <bschwab at anest.ufl.edu>wrote:
>
>> Sig,
>>
>> Short answer: I ****think***** the answer is to look for the #moduleName
>> as-given.  Screen against absolute paths if you want; Ubuntu won't care.
>>  Ubuntu demands that libraries be registered (using sudo+dlconfig) to
>> create a map that anyone can then read, either implicitly by loading the
>> library or explicitly using dlconfig.  It's suble, clever, and correct.
>>
>
>  Its not that easy.  Finding the correct libc first requires that one
> know what the libc name *is*.  linux has f***ed this up over the years,
> e.g. with "ld scripts" where /lib/libc.so.N was a piece of text one had to
> parse (!!), with hacking in the thread-local-storage version of pthreads
> via /lib/tls and /usr/lib/tls.  And now Ubuntu has put another layer in the
> process with /etc/ld.config.  The "linux" VM is supposed to run in all of
> these contexts.  So how does the VM/image combination map the nick-names of
> modules such as the C library and the OpenGL library into names that the
> module loading machinery can use reliably?
>
>
>  P.S.  This discussion belongs on vm-dev...
>
>
>> What I do NOT know how to do is enforce that policy in the vm.  I am
>> fairly confident that I can guide you or another vm jock to a correct
>> solution.
>>
>> Bill
>>
>>
>>
>> ________________________________________
>> From: pharo-project-bounces at lists.gforge.inria.fr [
>> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Igor Stasenko [
>> siguctua at gmail.com]
>> Sent: Tuesday, January 31, 2012 10:27 AM
>> To: Pharo-project at lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] CogVM driver vs executable
>>
>> On 31 January 2012 16:10, Sven Van Caekenberghe <sven at beta9.be> wrote:
>> > Thx for the reply, but as I said, I don't understand this library
>> loading, or why it has to be so complicated.
>> >
>> me neither.. so i don't even care to read this topic carefully.
>> i can't understand why we need such complex library lookup logic in VM
>> ,and other "driver" mechanisms.
>> i already proposed to move all this logic to image side, so at least
>> we could have a direct control of what happening,
>> as well as a good error handling in case of troubles.
>> while at VM, there should be a simplest possible thing to stay, a
>> function which takes a path to library
>> and reports a handle to it if it loaded it or error code, why it
>> cannot be loaded (file not found, lib file found but cannot be
>> initialized etc).
>>
>> > I am all for putting the maximum possible amount of control in the
>> image.
>> >
>> > In the mean time I saw that the driver is actually just a shell script
>> ;-) (I knew that but I guess I forgot).
>> >
>> > My main question remains: why is this necessary since it works without
>> the scipt just as well.
>> >
>> > Sven
>> >
>> > On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote:
>> >
>> >> Sven,
>> >>
>> >> I'm not sure what to tell you.   The "can't infer" message you are
>> experiencing ***might*** be the one time the vm is actually telling what's
>> wrong.  If so, it's PROGRESS.  Doesn't feel like that in your shoes, I
>> know....
>> >>
>> >> The bane of my existence is a silent failure (I dread those two word
>> in that sequence...) of the vm to look in the right place.  What did Nick
>> suggest to me?  strace, I think (it's in the archives).  You might run
>> under it to see if you can gain some insight; the tool in question does not
>> pt
>> >>
>> >> DON'T LET THIS HAPPEN TO YOU<g>: the tool in question[*] logs its
>> output to sterr(?), not stdout as one might expect.  If you try it, use the
>> -o option (I think) to direct to a file, then cat and grep are your
>> friends.  I remember "streaming" this into the archives, but I can't see
>> them to check the facts.
>> >>
>> >> I solved my problem by noting where the vm was actually looking and
>> making sym links to trick it (should not have to...) into working (very
>> good).  Let's all send kind thoughts to Sig - maybe he'll pull the search
>> policy into the image, where it belongs.  We will still want vm level
>> logging (syslog etc.) in case the image can't run.
>> >>
>> >> SECURITY: Ubuntu gets it right (took me a while to realize same) by
>> "forcing" us to use dlconfig to map names to libraries.  I don't really
>> understand it all, but I might be able to fake some useful answers if that
>> is confusing.  You might need to use dlconfig to "fix" Ubuntu, and then
>> links to fool the vm into looking where it should.
>> >>
>> >> HTH,
>> >>
>> >> Bill
>> >>
>> >>
>> >> [*] short term memory disorder<g>, which is precisely why we want
>> informative errors reaching the Smalltalk code (and?)/OR(ideal) being
>> logged (OutputDebugString or syslog) where one can readily find it.  Errors
>> rare enough that we get time to forget between them.  Pharo needs to help
>> us a bit more - afteall, it works for us, right?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ________________________________________
>> >> From: pharo-project-bounces at lists.gforge.inria.fr [
>> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Sven Van
>> Caekenberghe [sven at beta9.be]
>> >> Sent: Tuesday, January 31, 2012 3:30 AM
>> >> To: Pharo-project at lists.gforge.inria.fr Development
>> >> Subject: [Pharo-project] CogVM driver vs executable
>> >>
>> >> In response to my posting
>> >>
>> >>
>> http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.html
>> >>
>> >> I got feedback from people trying to use SSL with Eliot's CogVM
>> >>
>> >>  http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz
>> >>
>> >> instead of the Pharo one that I normally use
>> >>
>> >>  http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip
>> >>
>> >> They reported that it did not work for them.
>> >>
>> >> So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual
>> i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH.
>> Aborting.' which was discussed in this list before. I am not qualified to
>> really understand those discussions.
>> >>
>> >> But when I used the executable 'inside'
>> coglinux/lib/squeak/4.0-2522/squeak everything worked as expected.
>> >>
>> >> So the question is what does the driver (I don't know if that is the
>> right word) coglinux/squeak or coglinux/bin/squeak do ?
>> >> Since the pharo variant seems to operate fine without it, do we need
>> the driver ?
>> >>
>> >> Sven
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>>
>
>
>  --
> best,
> Eliot
>
>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120131/6b3aeacd/attachment-0001.htm