On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Sun, Jan 08, 2012 at 12:37:59AM +0000, Schwab,Wilhelm K wrote:
Eliot,
SOL?? Is that really the message we want to send to current and *prospective* users? Canonical does something that makes sense from a security perspective (one needs root privileges to alter the ldconfig mapping, not to to use it). All the vm needs to do is request the #moduleName as given, and users of Pharo "SOL" as a result?
Please reconsider.
Bill
I think you are taking the response out of context. The actual statement was "Then you're SOL :) You'd need to write new support for Ubuntu."
You might take that as a gentle suggestion to expend a bit of effort on it yourself. After all, it is open source, and Eliot is only one person. He can't do everything for everybody without a little help from the rest of us.
quite. i don't even have an ubuntu VM, let alone the time to work on it. Bill, instead of whining, pitch in, please.
Dave
________________________________ 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: Saturday, January 07, 2012 6:38 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found
On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu <mailto:bschwab@anest.ufl.edu>> wrote: Nick,
Partial success. After a false start with getting output from strace (my fault), it showed me that the vm was looking a lot in the vm's directory. A symlink by the same name, allowed it to see the library. Clearly, this is not a fix, because one should not be forced to make links to any/every library on the system. However, it *was* nice to see the version string in an inspector :)
Looking at the strace output (relevant parts below), it tries with prepending lib, appending .so, .so.dylib. It looks in the vm's directory, and in the root directory, not /usr/lib.
It has been almost a year (based on a dated comment) since I last really strained my synapses on the workings of ldconfig. On my systems, it would tell one to look for the library as follows:
ldconfig -p | grep Acces libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so
#moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and I use the term LOOSELY) understanding is that Ubuntu no longer uses LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as reported by ldconfig. The best explanation I have found is that the change was a security measure.
Then you're SOL :) You'd need to write new support for Ubuntu.
How does one get ldconfig to "know" where something lives? Putting a .so file in /usr/lib (and perhaps other places too) and then running ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can run this) will show the map, and one can grep the result to find something specifc, as above.
Putting files in /usr/lib is a pain for things under active development. A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the .conf files should contain paths to directories to be searched for .so files - or at least that's how it *appears* to work. Run ldconfig as sudo to refresh the mapping, and verify with ldconfig - p.
The fix might be as simply as having the cog vm try passing the #moduleName to dlopen().
Nick, thanks for the nudge in a working direction. I will probably symlink another file and see if a mix of hardware and software will get closer to cooperating with me.
Bill
-- best, Eliot