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

Eliot Miranda eliot.miranda at gmail.com
Mon Jan 9 19:34:38 CET 2012


On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <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 [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Eliot Miranda [
> eliot.miranda at gmail.com]
> > Sent: Saturday, January 07, 2012 6:38 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 8:49 AM, Schwab,Wilhelm K <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/28837004/attachment.htm>


More information about the Pharo-project mailing list