Hi Phil, I'm familiar with all this, but it doesn't help.
Suppose my code directly accesses "my.dll" which, in turn, depends on "her.dll" which my code does not need directly and suppose that library is located in folder "<path-to-her-folder>". How can I enforce the UFFI to perform the search there?
BTW, the URI you mention is not reachable. I usually use the following: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf On 2017-03-15 00:13, [email protected] wrote:
Yes there is. Search for the .so or .dll or .dylib strings with the finder and you will see a few and how they are found. Also check https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgresshttps://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.html where there are examples like Let's for example consider the library LibC already provided by uFFI: FFILibrary subclass: #LibC instanceVariableNames: '' classVariableNames: '' package: 'UnifiedFFI-Libraries' LibC>>macModuleName ^ 'libc.dylib' LibC>>unixModuleName ^ 'libc.so.6' LibC>>win32ModuleName "While this is not a 'libc' properly, msvcrt has the functions we are defining here" ^ 'msvcrt.dll' This is for libraries that are in the path or library path. One can come up with other strategies for loading these, with absolute path like '/usr/lib/xxx.so' Beware of the 32/64 bit thing< 32 bit pharo needs 32 bit lib. I am using a 32 bits container on linux to build 32 bits libraries, much less headaches. See https://gist.github.com/philippeback/33717128d5fb24263e557922d5ac913e HTH Phil
