Extension needs another DLL
in [TCL]
|
Prev: Where is IWidgets?
Next: Mouse over
From: Helmut Giese on 23 Mar 2010 08:06 Hello out there, consider the situation where you build a Tcl extension (ext.dll) which relies on another DLL (3rdparty.dll). - Your pkgindex.tcl arranges for ext.dll to be loaded. - When loading, the OS discovers that 3rdparty.dll is also needed and goes looking for it. This will work (Windows) as long as the cwd is the same directory as the one where all files making up your extension are found, but once you move everything to an appropriate place under .../lib it can easily fail, if 3rdparty.dll cannot be found anymore. Is there a remedy? I thought I once figured out a way to kind of "pre-load" 3rdparty.dll so that it was "present" once ext.dll would request it. However, I cannot remember how I did it. [load] seems to not be of any help here, since it wants a Tcl package and 3rdparty.dll is just a plain ol' DLL which knows nothing about Tcl. Possible solutions are - static linking of 3rdparty.dll into ext.dll, which may not be possible if you don't have sources, - putting 3rdparty.dll into a place where Windows will surely find it - but you may not have the priviliges to do so. Is there a way to solve this? Any idea will be greatly appreciated. Best regards Helmut Giese
From: Arjen Markus on 23 Mar 2010 09:58 On 23 mrt, 13:06, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > Hello out there, > consider the situation where you build a Tcl extension (ext.dll) which > relies on another DLL (3rdparty.dll). > - Your pkgindex.tcl arranges for ext.dll to be loaded. > - When loading, the OS discovers that 3rdparty.dll is also needed and > goes looking for it. > > This will work (Windows) as long as the cwd is the same directory as > the one where all files making up your extension are found, but once > you move everything to an appropriate place under .../lib it can > easily fail, if 3rdparty.dll cannot be found anymore. > > Is there a remedy? I thought I once figured out a way to kind of > "pre-load" 3rdparty.dll so that it was "present" once ext.dll would > request it. However, I cannot remember how I did it. > > [load] seems to not be of any help here, since it wants a Tcl package > and 3rdparty.dll is just a plain ol' DLL which knows nothing about > Tcl. Possible solutions are > - static linking of 3rdparty.dll into ext.dll, which may not be > possible if you don't have sources, > - putting 3rdparty.dll into a place where Windows will surely find it > - but you may not have the priviliges to do so. > > Is there a way to solve this? Any idea will be greatly appreciated. > Best regards > Helmut Giese You could extend the path environment variable for the duration of the [load] command: package ifneeded ext "[list set oldpath $::env(PATH)]; \ [list set ::env(PATH) [concat $dir $::Env(PATH)]; \ [list load $dir/ext.dll]; \ [list set ::env(PATH) $oldpath]" (Well, you get the drift) Regards, Arjen
From: Helmut Giese on 23 Mar 2010 10:42 Hi Arjen, >You could extend the path environment variable for the duration of the >[load] command: > >package ifneeded ext "[list set oldpath $::env(PATH)]; \ > [list set ::env(PATH) [concat $dir $::Env(PATH)]; \ > [list load $dir/ext.dll]; \ > [list set ::env(PATH) $oldpath]" > yes, this should work. (I suppose, one is still allowed to change the PATH under newer Windows versions. I don't know - I am sticking with XP as long as possible). Many thanks and best regards Helmut Giese
From: Arjen Markus on 23 Mar 2010 11:00 On 23 mrt, 15:42, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > Hi Arjen,>You could extend the path environment variable for the duration of the > >[load] command: > > >package ifneeded ext "[list set oldpath $::env(PATH)]; \ > > [list set ::env(PATH) [concat $dir $::Env(PATH)]; \ > > [list load $dir/ext.dll]; \ > > [list set ::env(PATH) $oldpath]" > > yes, this should work. (I suppose, one is still allowed to change the > PATH under newer Windows versions. I don't know - I am sticking with > XP as long as possible). > Many thanks and best regards > Helmut Giese The change is local to the Tcl process, so that should be allowed. As a package index script is not supposed to have side effects, it is a bit more complicated than just adding "dir" to the path, but it does not at any moment influence the OS as a whole. Newer versions of Windows (starting with XP) have the wonderful solution of side-by-side assembles to get you out of one particular version of the DLL hell. I always think it puts you in a new more sophisticated one, but, gosh, that is life and you better accept it if you want to work on Windows. Regards, Arjen
From: David Gravereaux on 23 Mar 2010 20:50
Helmut Giese wrote: > Is there a way to solve this? Any idea will be greatly appreciated. Instead of implicit linking to your 3rd party DLL, can you do it explicitly through LoadLibrary() and filling function pointers? LoadLibrary() can put you in-charge of the search path. The problem programatically is that deps are loaded by the OS prior your DllMain being run unless you use delay loading. Hmmm.. Have a look at delay loading -> http://msdn.microsoft.com/en-us/library/151kt790.aspx -- |