Cog+linux: external module not found

Eliot,

I'm getting an external library not found error on Ubuntu lucid with the Cog vm from

     http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip

The library lives in /usr/lib and is known to ldconfig by the name that I have specified in #moduleName.  What do I need to do?

Bill

Paul,

The library is 32 bit - I build it from source because it ships with 64 bit binaries.

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Paul DeBruicker [[hidden email]]
Sent: Friday, January 06, 2012 6:59 PM
To: [hidden email]

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

Schwab,Wilhelm K wrote
>
> Eliot,
>
> I'm getting the same error with your latest VM.  Any ideas?
>
> Bill
>
>
>

When I had trouble with this it was a 64bit vs 32bit library mismatch on a
64bit OS.

Is it a 32 bit or 64 bit OS?  Is the library you're trying to reach 32bit?
64bit libs won't work with the 32bit CogVM, but are installed by default by
the Ubuntu package manager on a 64bit Ubuntu.

Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from
their ia32-libs package to the ia32-libs-multiarch recently but I don't know
if that change affects Lucid.

--
View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hi Bill,

Have you tried strace to determine what library it's failing to load?

Nick

On 7 January 2012 03:26, Schwab,Wilhelm K <[hidden email]> wrote:

Eliot,

There is no /lib32 or /usr/lib32.  As a double check,

    locate lib32

returns nothing.  I put the library in /usr/lib, which is what I have done on two other Lucid systems.  ldconfig shows it registered there.

What's next?

Bill

---

From: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
Sent: Friday, January 06, 2012 7:29 PM

To: [hidden email]
Subject: Re: [Pharo-project] Cog+linux: external module not found

On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <[hidden email]> wrote:

Paul,

The library is 32 bit - I build it from source because it ships with 64 bit binaries.

Then try changing your LD_LIBRARY_PATH to /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have /lib32 & /usr/lib32 that is)

 

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Paul DeBruicker [[hidden email]]
Sent: Friday, January 06, 2012 6:59 PM
To: [hidden email]

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

Schwab,Wilhelm K wrote
>
> Eliot,
>
> I'm getting the same error with your latest VM.  Any ideas?
>
> Bill
>
>
>

When I had trouble with this it was a 64bit vs 32bit library mismatch on a
64bit OS.

Is it a 32 bit or 64 bit OS?  Is the library you're trying to reach 32bit?
64bit libs won't work with the 32bit CogVM, but are installed by default by
the Ubuntu package manager on a 64bit Ubuntu.

Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from
their ia32-libs package to the ia32-libs-multiarch recently but I don't know
if that change affects Lucid.

--
View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

--
best,

Eliot

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.

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

stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("./liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory)
read(10, ">externalCallFailed\nAccesIOUSBLi"..., 3424) = 3424
read(10, ">externalCallFailed\nAccesIOUSBLi"..., 4096) = 3424
write(10, "FileAccess: ", 12)           = 12
write(10, "SocketAccess: ", 14)         = 14
write(10, "an AccesIOUSBLibrary", 20)   = 20
write(10, "'libAccesIO-USB.so'", 19)    = 19
write(10, "an AccesIOUSBLibrary", 20)   = 20
write(10, "'libAccesIO-USB.so'", 19)    = 19
write(10, "an AccesIOUSBLibrary", 20)   = 20
write(10, "'libAccesIO-USB.so'", 19)    = 19
write(10, "an AccesIOUSBLibrary", 20)   = 20
write(10, "'libAccesIO-USB.so'", 19)    = 19
write(10, "#'Hardware-AccesIO'", 19)    = 19
write(10, "\t\ttextOrStream: \t'\t^AccesIOUSBLi"..., 65) = 65
write(10, "\t^ AccesIOUSBLibrary default AIO"..., 46) = 46
write(10, "a ReadStream '\t^AccesIOUSBLibrar"..., 61) = 61
write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27
write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27
write(10, "\t^AccesIOUSBLibrary defau...etc."..., 34) = 34

---

From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, January 07, 2012 8:55 AM

To: [hidden email]
Subject: Re: [Pharo-project] Cog+linux: external module not found

It would also be nice to see (either via syslog()/OutputDebugString()) or (if possible) in the error itself, what library (full path) was being loaded.  The output will generally be of interest only when something fails.

Similar comments would apply to serial ports that won't open - what did the vm actually try to do when something failed?  Most problems that I have had with getting Pharo to open something (library or port) have been relatively obvious to solve as soon as I saw how my intent was translated before it was passed on to the hardware (e.g. /usr/lib//this/that/something.so).

Bill

---

From: [hidden email] [[hidden email]] on behalf of Mariano Martinez Peck [[hidden email]]
Sent: Saturday, January 07, 2012 5:20 AM
To: [hidden email]
Subject: Re: [Pharo-project] Cog+linux: external module not found

BTW, Eliot, is there a way so that FFI throws something different from "Module not found" when the module is there but not 32 bits? like "Module found but it is not 32 bits" ?
cheers

On Sat, Jan 7, 2012 at 10:04 AM, Nick Ager <[hidden email]> wrote:

Hi Bill,

Have you tried strace to determine what library it's failing to load?

Nick

On 7 January 2012 03:26, Schwab,Wilhelm K <[hidden email]> wrote:

Eliot,

There is no /lib32 or /usr/lib32.  As a double check,

    locate lib32

returns nothing.  I put the library in /usr/lib, which is what I have done on two other Lucid systems.  ldconfig shows it registered there.

What's next?

Bill

---

From: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
Sent: Friday, January 06, 2012 7:29 PM

To: [hidden email]
Subject: Re: [Pharo-project] Cog+linux: external module not found

On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <[hidden email]> wrote:

Paul,

The library is 32 bit - I build it from source because it ships with 64 bit binaries.

Then try changing your LD_LIBRARY_PATH to /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have /lib32 & /usr/lib32 that is)

 

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Paul DeBruicker [[hidden email]]
Sent: Friday, January 06, 2012 6:59 PM
To: [hidden email]

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

Schwab,Wilhelm K wrote
>
> Eliot,
>
> I'm getting the same error with your latest VM.  Any ideas?
>
> Bill
>
>
>

When I had trouble with this it was a 64bit vs 32bit library mismatch on a
64bit OS.

Is it a 32 bit or 64 bit OS?  Is the library you're trying to reach 32bit?
64bit libs won't work with the 32bit CogVM, but are installed by default by
the Ubuntu package manager on a 64bit Ubuntu.

Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from
their ia32-libs package to the ia32-libs-multiarch recently but I don't know
if that change affects Lucid.

--
View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

--
best,

Eliot

--
Mariano
http://marianopeck.wordpress.com

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.

Dave

>
>
>
> ________________________________
> From: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
> Sent: Saturday, January 07, 2012 6:38 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Cog+linux: external module not found
>
>
>

> On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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
>

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: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]

Sent: Monday, January 09, 2012 1:34 PM

To: [hidden email]
Subject: Re: [Pharo-project] Cog+linux: external module not found

On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
> Sent: Saturday, January 07, 2012 6:38 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Cog+linux: external module not found
>
>
>

> On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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