On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K bschwab@anest.ufl.eduwrote:
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-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [ siguctua@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 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.htm...
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.
On 31 January 2012 21:06, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K bschwab@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?
thats why i urge for putting all this stuff in image side, leaving VM code as dumb as possible. let image developers have a headache about loading library from right place, but not VM developers.
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-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@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 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.htm...
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
Eliot,
You are correct about the name mangling, but that's a second level. With all due respect, Cog starts the search in the wrong place. I hope we can sort it out.
If the rock and the hard place keep coming after us, maybe we need in in-image (where it can be readily seen and modified) registry of names. The current approach is not working (I know you've worked hard, but more is needed).
Sounds like I need to start reading vm-dev - will do.
Bill
________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda@gmail.com] Sent: Tuesday, January 31, 2012 3:06 PM To: Pharo-project@lists.gforge.inria.fr Cc: Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] CogVM driver vs executable
On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edumailto:bschwab@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-bounces@lists.gforge.inria.frmailto:pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.frmailto:pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.commailto:siguctua@gmail.com] Sent: Tuesday, January 31, 2012 10:27 AM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] CogVM driver vs executable
On 31 January 2012 16:10, Sven Van Caekenberghe <sven@beta9.bemailto: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.frmailto:pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.frmailto:pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.bemailto:sven@beta9.be] Sent: Tuesday, January 31, 2012 3:30 AM To: Pharo-project@lists.gforge.inria.frmailto: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.htm...
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
On Tue, Jan 31, 2012 at 2:21 PM, Schwab,Wilhelm K bschwab@anest.ufl.eduwrote:
Eliot,
You are correct about the name mangling, but that's a second level. With all due respect, Cog starts the search in the wrong place. I hope we can sort it out.
I didn't write the search machinery. So what does it do and what should it do, IYO?
If the rock and the hard place keep coming after us, maybe we need in in-image (where it can be readily seen and modified) registry of names. The current approach is not working (I know you've worked hard, but more is needed).
Sounds like I need to start reading vm-dev - will do.
Bill
*From:* pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [ eliot.miranda@gmail.com] *Sent:* Tuesday, January 31, 2012 3:06 PM *To:* Pharo-project@lists.gforge.inria.fr *Cc:* Squeak Virtual Machine Development Discussion *Subject:* Re: [Pharo-project] CogVM driver vs executable
On Tue, Jan 31, 2012 at 7:34 AM, Schwab,Wilhelm K bschwab@anest.ufl.eduwrote:
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-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [ siguctua@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 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.htm...
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
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
Schwab,Wilhelm K