phil@highoctane.be wrote:
Yes, all of this should work and we need to improve on this.
I am willing to do something about that because it frustrates me too.
Herby,
How would you see it working?
Hard to answer. But linux knows where its libs are, at least when you do `/sbin/ldconfig -p` in CLI. Pharo should probably use this info somehow, question is, is there a kernel API to get to this, or is there another sane way to get to it? Of course, accepting 'libfoo' when asking for 'foo', but that probably is there already (I hope). And of course, honouring LD_LIBRARY_PATH, as it _is_ set in the pharo start script, so maybe even used, but... I am sorry I don't know how shared lib resolving works on linux. I am just the "as far as I can tell, the whole point of shared libraries is to ask OS for them and get them handed over" kind of person here. Ppl love Smalltalk so much, they forgive lots of rough edges - I think we should not be that forgiving (like, garbled utf-8 names read from git in iceberg-metacello integration; and there are lots of details like this, the issue in this thread being one of more serious ones of them. IMO). Herby
Phil
On Mon, Oct 2, 2017 at 1:45 PM, Herby VojÄÃk <herby@mailbox.sk <mailto:herby@mailbox.sk>> wrote:
Renaud de Villemeur wrote:
Hi
[...snip...]
The reason it pass under windows is because the method library return by default sqlite3, which is the dll name you put under pharo VM directory to get it work.
Not true. It is not in pharo vm directory. It finds it on %PATH%.
On linux, unless you link your library in the VM folder, the image has no clue where to find sqlite3.
And this should be fixed, IMNSHO. It probably _partly_ works, but it should be made to work better.
Herby
Hope this helps. Renaud
.
.