Prev: beautiful user interface, is it hard to do?
Next: passing "arrays of structs" in procs.
From: JHJL on 5 Mar 2010 05:30
Hi all

I have a an application which uses a C extension DLL which provides a
package I call Wpl. This works fine when running the application with
tclsh85 and wish85.

I am now trying to use Tclapp (part of TclDevKit) to create a
standalone version of the application. I can create the application OK
but when I come to run it I am getting an error generated by the load
command:

couldn't load library "E:/tmp/srec2was.exe/lib/P-win32-ix86/Wpl3.1.1/
wpl.dll": No error while executing "load [file join {E:/tmp/
srec2was.exe/lib/P-win32-ix86/Wpl3.1.1} wpl.dll]" (package ifneeded
Wpl 3.1.1" script)

[Note that the above was hand typed because I cannot access the
internet from my development machine].

One thing to mention is that wpl.dll depends on 3 other non-Tcl DLLs
which are already installed on the system and not part of the package.

Any help pointers gratefully recieved

kind regards
Julian H J Loaring
From: Patrick on 5 Mar 2010 13:13
I assume you have your extension dll wrapped in the starkit. It is my
experience that this worked fine UNLESS the dll depends on other
external dlls. Since the dll is stored in the starkit's internal
virtual filessystem, anything it depends on must be in the vfs as
well.

I would suggest this as a starting point: remove the Wpl library from
the starkit and place in a lib directory where the srec2was.exe
resides. Then make sure you tell the tcl interpreter where to search
for libraries using the following:

set ::HOME [file dirname [info nameofexecutable]]
lappend ::auto_path $::HOME/lib

If the other three dlls are something that you distribute you should
either be able to place them in $::HOME/lib or $::HOME. If they are
dlls that are part of windows or otherwise in system32, then there
should be no problem finding them.

If these others are part of your dist, you may be able to wrap them in
your Wpl lib as well. However regardless at runtime they get unwrapped
to temp directory every time they run so you may find it better to
keep all dlls unwrapped.

Lastly, Dependency Walker is a good tool to use to figure out the dll
dependencies, but has limited benefit with starkit exes.



From: JHJL on 5 Mar 2010 13:44
On Mar 5, 6:13 pm, Patrick <patrick.dunni...(a)activecompliance.com>
wrote:
> I assume you have your extension dll wrapped in the starkit. It is my
> experience that this worked fine UNLESS the dll depends on other
> external dlls. Since the dll is stored in the starkit's internal
> virtual filessystem, anything it depends on must be in the vfs as
> well.
>
> I would suggest this as a starting point: remove the Wpl library from
> the starkit and place in a lib directory where the srec2was.exe
> resides. Then make sure you tell the tcl interpreter where to search
> for libraries using the following:
>
> set ::HOME [file dirname [info nameofexecutable]]
> lappend ::auto_path $::HOME/lib
>
> If the other three dlls are something that you distribute you should
> either be able to place them in $::HOME/lib or $::HOME. If they are
> dlls that are part of windows or otherwise in system32, then there
> should be no problem finding them.
>
> If these others are part of your dist, you may be able to wrap them in
> your Wpl lib as well. However regardless at runtime they get unwrapped
> to temp directory every time they run so you may find it better to
> keep all dlls unwrapped.
>
> Lastly, Dependency Walker is a good tool to use to figure out the dll
> dependencies, but has limited benefit with starkit exes.

Many thanks for such a detailed tip. I will not be able to try this
until I am back in office on Monday but will post my progress here
then.

kind regards
Julian

 | 
Pages: 1
Prev: beautiful user interface, is it hard to do?
Next: passing "arrays of structs" in procs.