[email protected] 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 <[email protected]
<mailto:[email protected]>> 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
.
.
