Hi Dan 2017-09-23 13:24 GMT-03:00 Dan Wilczak <dan.g.wilc...@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 <esteba...@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.s...@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.wilc...@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 >> >> >> > >> >> >
