[Pharo-project] Cog+linux: external module not found

Schwab,Wilhelm K bschwab at anest.ufl.edu
Mon Jan 9 19:55:31 CET 2012


Eliot,

Whining - that's a bit much.  In fact it is TOTALLY unjustified.

Last year, I spent (end to end) months learning how to get away from creating my own hacked vms - that's how I knew about ldconfig's behavior , and have come to appreciate that Canonical got this one right.

Recently, I spent hours running down why Cog fails to find properly installed libraries on a major Linux platform.  I'd say that's "pitching in."  It sure isn't whining!!

Am I certain of all the details of what should happen and why?  No.  Am I the best person to tell the vm to stop looking here/there/everywhere and just use the module name as given?  Certainly not.  I *thought* you might want to do that yourself, so it gets done properly.

I also thought you might appreciate some help in debugging a problem.  Instead you tell me that I am an SOL whiner.  Not good.

Bill



________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda at gmail.com]
Sent: Monday, January 09, 2012 1:34 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Cog+linux: external module not found



On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <lewis at mail.msen.com<mailto:lewis at 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 at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr> [pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda at gmail.com<mailto:eliot.miranda at gmail.com>]
> Sent: Saturday, January 07, 2012 6:38 PM
> To: Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at 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 at anest.ufl.edu<mailto:bschwab at anest.ufl.edu><mailto:bschwab at anest.ufl.edu<mailto:bschwab at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120109/4cb5867d/attachment.htm>


More information about the Pharo-project mailing list