On 31 January 2012 16:10, Sven Van Caekenberghe <[email protected]> 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: [email protected] >> [[email protected]] on behalf of Sven Van >> Caekenberghe [[email protected]] >> Sent: Tuesday, January 31, 2012 3:30 AM >> To: [email protected] 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.
