Hi Dan 2017-09-23 13:24 GMT-03:00 Dan Wilczak <dan.g.wilczak@gmail.com>:
It does search on LD_LIBRARY_PATH now, it just fails because it finds the 32-bit libcairo before the 64-bit one.
The traceback displayed inside Pharo says "Error: External module not found" which is quite misleading. A minimal fix would be to just provide a better error message.
Yes, better error messages saves a lot of time. Have you opened an issue for this?
There is a traceback that prints to the console if you launched pharo from it, and it does reveal the true failure, but only to someone who knows what ELFCLASS32 means:
ioLoadModule(//usr/lib/libcairo.so.2): //usr/lib/libcairo.so.2: wrong ELF class: ELFCLASS32 Error: External module not found
This shows that the information for a better error message is available.
A better fix would be to skip the 32-bit lib and keep searching. This looks like it would be messy because CairoLibrary provides the path but U FFI has to deal with it.
You mean keep searching the whole file system?
As far as I can see, there's no way to just check whether a library is 32- or 64-bit, other than trying to call something in it.
One can use a fork() or exec() with the "file" command in Linux based OS, to find library type. It will answer something like: ELF 32-bit LSB shared object, Intel80386, version 1, not stripped or ELF 64-bit LSB shared object, version 1, not stripped
I'm a total Pharo novice (I wrote maybe 300 lines of Squeak code several years ago) but this design seems odd to me. Why is LD_LIBRARY_PATH being handled in Athens-Cairo rather than UFFI itself?
Dan
On Sat, Sep 23, 2017 at 4:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi,
this is not a bug, UFFI cannot know where a library is (because it can be anywhere). but, not being a bug, this remains a problem :) One solution is to search on LD_LIBRARY_PATH but this is not generalised (it should) for the moment. And of course, this is a solution that works for linux and not other platforms, so not perfect. Also we need to consider architecture, etc. etc. etc.
Esteban
On 23 Sep 2017, at 09:16, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Can you open a bug entry and propose your solution?
Stef
On Fri, Sep 22, 2017 at 9:56 PM, Dan Wilczak <dan.g.wilczak@gmail.com> wrote:
That pointed me in the right direction, thanks. I've got it working now.
I think there's a bug there which may bite other people ---
If you have both 32-bit and 64-bit versions of the library installed, Unix64ModuleName can find the 32-bit version first (depending on your LD_LIBRARY_PATH) and set that as the lib to use. Then when UFFI loads it, it recognizes it as 32-bit and gives up rather than looking in any more directories.
Dan
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html