On 31 January 2012 16:10, Sven Van Caekenberghe <
sven@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@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [
sven@beta9.be]
>> Sent: Tuesday, January 31, 2012 3:30 AM
>> To:
Pharo-project@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.