[Pharo-project] CogVM driver vs executable
eliot.miranda at gmail.com
Tue Jan 31 15:06:39 EST 2012
On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K <bschwab at anest.ufl.edu>wrote:
> 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
> 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
> >> 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
> >> 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
> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev