March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] Mini Pharo -> JavaScript translator?

by Alexandre Bergel

Thanks for your answers! We will have a close look at this. Cheers, Alexandre > On Mar 14, 2017, at 6:43 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > You mean this one (attached)? > > How would I use it standalone to translate Smalltalk to JavaScript? > > --Hannes > > On 3/14/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Hi Dave, >> >> I was looking for the class you mention, JSCodeGenerator in the >> VMMaker repository, but I did not find it. >> >> Where do I need to go? >> >> Regards >> >> --Hannes >> >> On 3/11/17, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> On Sat, Mar 11, 2017 at 06:16:26AM +0100, H. Hirzel wrote: >>>> On 3/10/17, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> Hi! >>>>> >>>>> Is there a simple way to translate Pharo code into Javascript? >>>>> There is Pharo JS, but I cannot load it in Pharo 6. There is the amber >>>>> compiler, but I cannot find a version for Pharo. >>>>> >>>>> Amber takes the approach of translating everything into JavaScript, >>>>> including the Smalltalk object model. While this is great for fan of >>>>> bootstrapping images, it produces large javascript code. >>>>> >>>>> Is there a kind of Slang for JavaScript? I am looking for something >>>>> minimal. >>>>> >>>>> Cheers, >>>>> Alexandre >>>> >>>> >>>> Hello Alexandre >>>> >>>> >>>> Something like this >>>> https://github.com/ympbyc/LittleSmallscript >>>> >>>> or >>>> >>>> >>>> http://wiki.squeak.org/squeak/5860 which refers to >>>> http://www.squeaksource.com/@xxu3r2Ma7SbqJi3E/1j-SgMCf (74000 >>>> downloads). >>>> >>>> People have used it successfully. >>>> >>>> There is probably a Pharo port. >>>> >>> >>> There is also an actual Slang code generator for Javascript, written >>> by Bert Freudenburg and used to generated the VM plugins for the >>> SqueakJS VM. You can find it in the VMMaker package (not VMMaker.oscog) >>> at http://source.squeak.org/VMMaker, see class JSCodeGenerator. >>> >>> Dave >>> >>> >>> >> > <VMMakerJS_bf_Screenshot_2017-03-14.png> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 15, 2017

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

by Raffaello Giulietti

Hi Dimitris, I don't get your point about proper C coding, C performance or Pharo crashes. It is not the focus of this thread. How dependencies between libraries are resolved at load-time is dictated by the OS. If the OS offers a working mechanism to specify folders that the OS uses to search for libraries at load-time, well, I think that Pharo, hence the UFFI, should offer it as well and in a more fashionable format. UFFI is quite elegant in many respects but I wouldn't call it a minimalist design (zero hand holding, if I understand you correctly). But I'm happy the extra elegance is there because it makes life more comfortable. Again, I still have to experiment with SetDllDirectory() in the case of Windows, so I'm not in a position to say something authoritative yet. On 2017-03-15 17:41, Dimitris Chloupis wrote: > Please note the moment you use a FFI of any language you step to a C > territory. VMs tend not to touch the code because the code is already > in machine code format. > > There is zero reason for UFFI to worry about the dependencies of a > library loaded, this must happen at the library level that UFFI does > not focus on. > > What you describe here is standard practice because the vast majority > of libraries depend on other libraries. In the end UFFI or any FFI in > any language is not there to replace proper C coding but rather to > allow you to utilize C libraries. You cannot hope to achieve > performance comparable to C if you try to use a language that is not C > to do standard things like dependency management. > > If the library fail to load it wont be because of UFFI it will be > because the library is buggy at handling its dependencies. That means > that the library will be buggy even if you use it from C directly. > > Even you do not know what you doing at C level, you going to crash > Pharo countless times anyway and the least of your worries will be > handling dependencies which far more obvious than some other nasty C > bugs. > > I think its a great idea that UFFI does zero hand holding. This way it > gives the clear message that if you do not understand C then you > should not be using the UFFI in the first place. > > On Wed, Mar 15, 2017 at 4:51 PM Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > > > On 15 Mar 2017, at 15:44, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> wrote: > > > > On 2017-03-15 15:20, Esteban Lorenzano wrote: > >> > >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@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? > > I really have no idea. You can try to add it to your app. > > Esteban > > > > > > > > > > >> 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.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> wrote: > >>>>> > >>>>> On 2017-03-15 13:51, Ben Coman wrote: > >>>>>> > >>>>>> > >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti > >>>>>> <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > >>>>>> <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@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 > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > >

March 15, 2017

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

by Dimitris Chloupis

Please note the moment you use a FFI of any language you step to a C territory. VMs tend not to touch the code because the code is already in machine code format. There is zero reason for UFFI to worry about the dependencies of a library loaded, this must happen at the library level that UFFI does not focus on. What you describe here is standard practice because the vast majority of libraries depend on other libraries. In the end UFFI or any FFI in any language is not there to replace proper C coding but rather to allow you to utilize C libraries. You cannot hope to achieve performance comparable to C if you try to use a language that is not C to do standard things like dependency management. If the library fail to load it wont be because of UFFI it will be because the library is buggy at handling its dependencies. That means that the library will be buggy even if you use it from C directly. Even you do not know what you doing at C level, you going to crash Pharo countless times anyway and the least of your worries will be handling dependencies which far more obvious than some other nasty C bugs. I think its a great idea that UFFI does zero hand holding. This way it gives the clear message that if you do not understand C then you should not be using the UFFI in the first place. On Wed, Mar 15, 2017 at 4:51 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 15 Mar 2017, at 15:44, Raffaello Giulietti < > raffaello.giulietti(a)lifeware.ch> wrote: > > > > On 2017-03-15 15:20, Esteban Lorenzano wrote: > >> > >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti < > raffaello.giulietti(a)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? > > I really have no idea. You can try to add it to your app. > > Esteban > > > > > > > > > > >> 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.giulietti(a)lifeware.ch> wrote: > >>>>> > >>>>> On 2017-03-15 13:51, Ben Coman wrote: > >>>>>> > >>>>>> > >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti > >>>>>> <raffaello.giulietti(a)lifeware.ch > >>>>>> <mailto:raffaello.giulietti@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 > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > >

March 15, 2017

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

by Esteban Lorenzano

> On 15 Mar 2017, at 15:44, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > On 2017-03-15 15:20, Esteban Lorenzano wrote: >> >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti <raffaello.giulietti(a)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? I really have no idea. You can try to add it to your app. Esteban > > > > >> 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.giulietti(a)lifeware.ch> wrote: >>>>> >>>>> On 2017-03-15 13:51, Ben Coman wrote: >>>>>> >>>>>> >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >>>>>> <raffaello.giulietti(a)lifeware.ch >>>>>> <mailto:raffaello.giulietti@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 >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

March 15, 2017

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

by Raffaello Giulietti

On 2017-03-15 15:20, Esteban Lorenzano wrote: > >> On 15 Mar 2017, at 15:08, Raffaello Giulietti <raffaello.giulietti(a)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.giulietti(a)lifeware.ch> wrote: >>>> >>>> On 2017-03-15 13:51, Ben Coman wrote: >>>>> >>>>> >>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >>>>> <raffaello.giulietti(a)lifeware.ch >>>>> <mailto:raffaello.giulietti@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 >>>>> >>>> >>>> >>> >>> >> >> > >

March 15, 2017

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

by Esteban Lorenzano

> On 15 Mar 2017, at 15:08, Raffaello Giulietti <raffaello.giulietti(a)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. 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.giulietti(a)lifeware.ch> wrote: >>> >>> On 2017-03-15 13:51, Ben Coman wrote: >>>> >>>> >>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >>>> <raffaello.giulietti(a)lifeware.ch >>>> <mailto:raffaello.giulietti@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 >>>> >>> >>> >> >> > >

March 15, 2017

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

by Raffaello Giulietti

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. 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.giulietti(a)lifeware.ch> wrote: >> >> On 2017-03-15 13:51, Ben Coman wrote: >>> >>> >>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@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 >>> >> >> > >

March 15, 2017

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

by Esteban Lorenzano

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.giulietti(a)lifeware.ch> wrote: > > On 2017-03-15 13:51, Ben Coman wrote: >> >> >> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@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 >> > >

March 15, 2017

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

by Raffaello Giulietti

On 2017-03-15 13:51, Ben Coman wrote: > > > On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@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 >

March 15, 2017

Re: [Pharo-users] snap package can't find vm-display-X11

by Alistair Grant

On 14 March 2017 at 18:30, stepharong <stepharong(a)free.fr> wrote: > This is super good that you are pushing this packaging. Yep, I wasn't looking forward to enabling i386 architecture, etc. on my home server (which I'm hoping not to upgrade for several years). This way I can have Pharo running on a fairly minimal system (in terms of installed software). Cheers, Alistair

March 15, 2017