[Pharo-project] CogVM driver vs executable

Schwab,Wilhelm K bschwab at anest.ufl.edu
Tue Jan 31 10:34:44 EST 2012


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.

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.





More information about the Pharo-dev mailing list