On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K <bsch...@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-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [ > siguc...@gmail.com] > Sent: Tuesday, January 31, 2012 10:27 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] CogVM driver vs executable > > On 31 January 2012 16:10, Sven Van Caekenberghe <s...@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-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sven Van > Caekenberghe [s...@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. > > > -- best, Eliot