<br><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K <span dir="ltr"><<a href="mailto:bschwab@anest.ufl.edu">bschwab@anest.ufl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sig,<br>
<br>
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.<br>
</blockquote><div><br></div><div>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?</div>
<div> </div><div><br></div><div>P.S. This discussion belongs on vm-dev...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
Bill<br>
<br>
<br>
<br>
________________________________________<br>
From: <a href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a> [<a href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a>] on behalf of Igor Stasenko [<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>]<br>
Sent: Tuesday, January 31, 2012 10:27 AM<br>
To: <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
Subject: Re: [Pharo-project] CogVM driver vs executable<br>
<div><div></div><div class="h5"><br>
On 31 January 2012 16:10, Sven Van Caekenberghe <<a href="mailto:sven@beta9.be">sven@beta9.be</a>> wrote:<br>
> Thx for the reply, but as I said, I don't understand this library loading, or why it has to be so complicated.<br>
><br>
me neither.. so i don't even care to read this topic carefully.<br>
i can't understand why we need such complex library lookup logic in VM<br>
,and other "driver" mechanisms.<br>
i already proposed to move all this logic to image side, so at least<br>
we could have a direct control of what happening,<br>
as well as a good error handling in case of troubles.<br>
while at VM, there should be a simplest possible thing to stay, a<br>
function which takes a path to library<br>
and reports a handle to it if it loaded it or error code, why it<br>
cannot be loaded (file not found, lib file found but cannot be<br>
initialized etc).<br>
<br>
> I am all for putting the maximum possible amount of control in the image.<br>
><br>
> In the mean time I saw that the driver is actually just a shell script ;-) (I knew that but I guess I forgot).<br>
><br>
> My main question remains: why is this necessary since it works without the scipt just as well.<br>
><br>
> Sven<br>
><br>
> On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote:<br>
><br>
>> Sven,<br>
>><br>
>> 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....<br>
>><br>
>> 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<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> HTH,<br>
>><br>
>> Bill<br>
>><br>
>><br>
>> [*] 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?<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> ________________________________________<br>
>> From: <a href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a> [<a href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a>] on behalf of Sven Van Caekenberghe [<a href="mailto:sven@beta9.be">sven@beta9.be</a>]<br>
>> Sent: Tuesday, January 31, 2012 3:30 AM<br>
>> To: <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a> Development<br>
>> Subject: [Pharo-project] CogVM driver vs executable<br>
>><br>
>> In response to my posting<br>
>><br>
>> <a href="http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.html" target="_blank">http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.html</a><br>
>><br>
>> I got feedback from people trying to use SSL with Eliot's CogVM<br>
>><br>
>> <a href="http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz" target="_blank">http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz</a><br>
>><br>
>> instead of the Pharo one that I normally use<br>
>><br>
>> <a href="http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip" target="_blank">http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip</a><br>
>><br>
>> They reported that it did not work for them.<br>
>><br>
>> 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.<br>
>><br>
>> But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected.<br>
>><br>
>> 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 ?<br>
>> Since the pharo variant seems to operate fine without it, do we need the driver ?<br>
>><br>
>> Sven<br>
>><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>