Re: [Pharo-users] Specifying library dependencies in UFFI

[Raffaello Giulietti]

On 2017-03-15 15:20, Esteban Lorenzano wrote:

On 15 Mar 2017, at 15:08, Raffaello Giulietti <raffaello.giulie...@lifeware.ch> 
wrote:

Hi Esteban,

I understand this is the current status of the UFFI, so I can certainly use the 
workarounds discussed below.

But I hope UFFI will soon offer a more "declarative" way to specify the search 
folders, kind of LD_LIBRARY_PATH mechanism but in the UFFI.

that will NOT solve the problem of dependencies of libraries indirectly 
references.
There is no way to do that (indirect reference solving) on an executing program 
that I know.
So is not “current status of UFFI”: it will never provide that.


Do you mean that SetDllDirectory() has no influence when invoked between 
Pharo's start and the LoadLibrary() call done by the UFFI?




All that, unless someone come and says: "look, Esteban is like this”.

I spent last three weeks (not full time of course) trying to do exactly that 
for our current linux vm, to force libgit2 to use the version of libssh2 we 
want (and not the version on system)… and I failed. I solved some cases, but 
not all. So at the end I opted to change zeroconf to define LD_LIBRARY_PATH 
before calling pharo. Only way I found I can force the lookup paths.

cheers,
Esteban




Greetings
Raffaello




On 2017-03-15 14:52, Esteban Lorenzano wrote:
Hi,

UFFI cannot do what you want.
If I understand well, you have:

Pharo -> libA.dll -> libB.dll

Pharo does a LoadLibrary(libA.dll), but has no control on how libA calls libB… 
and is not possible for us to influence it more than the predefined platform 
ways.

One posible workaround (just possible, no idea if it will work) is to perform a 
load of libB before is required by libB. Then hopefully the loader will 
understand is same library and will answer same handler (but not sure, because 
if it discriminates by path… then you’re in the same position). Anyway, if you 
want to try it, it would be something like this:

DynamicLoader loadLibrary: 'path/to/libB.dll’.
DynamicLoader loadLibrary: 'path/to/libA.dll’.

then you can try to execute functions of libA…

cheers,
Esteban


On 15 Mar 2017, at 14:32, Raffaello Giulietti <raffaello.giulie...@lifeware.ch> 
wrote:

On 2017-03-15 13:51, Ben Coman wrote:


On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti
<raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>> wrote:

  Hi Ben,

  my understanding is that SetDllDirectory only affects the search
  path of libraries that are loaded at *run-time* with LoadLibrary.

  What I'm asking for is a mechanism that works at *load-time*, when a
  library I'm accessing directly depends on another one which I'm not
  targeting directly.


I don't quite follow.  I'm not intimate with Windows dynamic loading, so
these questions are an opportunity for me to learn...

You can't mean when Pharo loads, because it wouldn't know of OTHER.DLL ?

Do you mean that LoadLibrary is not called explicitly by YOUR.DLL before
its uses the function from OTHER.DLL?


During the build of YOUR.DLL, you can specify that it should depend on OTHER.LIB (kind of 
binary which lists function headers and static data declarations for OTHER.DLL). Linking 
resolution is then done at load-time of YOUR.DLL, not by invoking 
LoadLibrary("OTHER.DLL").

When YOUR.DLL is loaded by UFFI at run-time (here by means of LoadLibrary(), I 
guess), Windows (not the UFFI) also attempts to load OTHER.DLL because of the 
linking information gathered during the build. Notice that the linking 
information does *not* include a specific path for OTHER.DLL.

(You don't have to mention standard *.LIBs like Kernel32.lib because they are 
included by default. But of course, Windows knows where to find the 
corresponding .dll.)

OTHER.DLL is searched using the strategy described in the MSDN page you 
mention. My expectation is/was that UFFI has/had an API for specifying the 
search paths where to find OTHER.DLL in a platform-independent way. In other 
words, I would expect the UFFI to do the call of SetDllDirectory() or whatever 
is needed on Windows for me or to use other mechanisms on other platforms.



Do you mean you link OTHER.DLL to YOUR.DLL at compile time?
But still, YOUR.DLL it not loaded until called via Pharo FFI, so neither
is OTHER.DLL,
and Dynamic-Link Library Search Order [1] says... "If a DLL with the
same module name
is already loaded in memory, the system uses the loaded DLL, no matter
which directory it is in.
The system does not search for the DLL."

So maybe before calling any of YOUR.DLL,
do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL)
and later when you call into YOUR.DLL,
OTHER.DLL is already loaded.


Yes, this might work but is rather contrived.



Otherwise it would seems(?) your options are either Manifests
or Dynamic-Link Library Redirection, both done outside of Pharo.


What if neither YOUR.DLL nor OTHER.DLL are under my control? The only thing I 
know is where the .dll and the corresponding .lib + .h are.



Thanks for your interest
Raffaello




  But I'll try whether SetDllDirectory also affects load-time searches.

  Anyway, I hope future versions of the UFFI to offer setting the
  search paths more easily.



  Greetings
  Raffaello