I'm definitely not interested in help from someone who flies off the handle like this. Plonk.
On Mon, Jan 9, 2012 at 10:55 AM, Schwab,Wilhelm K <bsch...@anest.ufl.edu>wrote: > 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-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.mira...@gmail.com] > *Sent:* Monday, January 09, 2012 1:34 PM > > *To:* Pharo-project@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 <le...@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-boun...@lists.gforge.inria.fr [ >> pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [ >> eliot.mira...@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 < >> bsch...@anest.ufl.edu<mailto:bsch...@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 > > -- best, Eliot
