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: [email protected] [[email protected]] on behalf of Eliot Miranda [[email protected]] Sent: Monday, January 09, 2012 1:34 PM To: [email protected] Subject: Re: [Pharo-project] Cog+linux: external module not found On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <[email protected]<mailto:[email protected]>> 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: > [email protected]<mailto:[email protected]> > > [[email protected]<mailto:[email protected]>] > on behalf of Eliot Miranda > [[email protected]<mailto:[email protected]>] > Sent: Saturday, January 07, 2012 6:38 PM > To: > [email protected]<mailto:[email protected]> > Subject: Re: [Pharo-project] Cog+linux: external module not found > > > > On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > 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
