Oh my, am doing too much Windows at the moment. Phil On Sat, Oct 7, 2017 at 11:47 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Sat, Sep 30, 2017 at 01:28:06PM +0200, Herby Voj????k wrote:
phil@highoctane.be wrote:
What about
LD_LIBRARY_PATH=<sqlite3place>;$LD_LIBRARYPATH ./pharo-ui some.image
Phil
Thanks for answer, did not help.
In fact it must be something different. As can be seen in the stack, it fails during finalizers, and as can be seen by looking at UDBCSQLite3DatabaseExternalObject class>>finalizeResourceData: code, the method it calls is sqlite close. It is hardly the first method that is should call...
I suspect something around image save / load. Again. Lots of errors in those parts. But may be something else, as it kicks in only when SQLite-using tests starts to run. :-(
Herby
P.S.: I saw there is a similar thread out there, but it has problems with 32bit loaded by 64bit vm; but here, I have 32bit linux, so the vm installed should be 32bit.
Sorry I'm a bit late to the party...
I'm using Glorp / UDBCSQLite3 on Ubuntu 16.04 without any problems (admittedly 64 bit Ubuntu, but as you say, that shouldn't matter).
Just in case you copy-and-pasted the code, Phil's example has a typo: the path separator is a colon (:), not semicolon (;).
Install libsqlite3-dev and adding /usr/lib/i386-linux-gnu to LD_LIBRARY_PATH is all I had to do to get it to work (no changes to UDBCSQLite3Library>>library). Actually LD_LIBRARY_PATH normally shouldn't be required, but I'm running inside a snap container, which is an unusual environment.
root@32bit-agent:~# find / -name '*libsqlite*' -type f
2>>/dev/null
/usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6
It seems strange that there isn't libsqlite3.so. I think the real solution would be to find out why libsqlite3.so doesn't exist, but after installing libsqlite3-dev, a workaround would be to try creating a symbolic link from libsqlite3.so.0.8.6 to libsqlite3.so.
Cheers, Alistair