link statically

link statically

[Giampiero Salvi]

Hi all,
I've been using pthreads-win32 the develop a tcl library.
Everything has been working fine, provided that I had the
pthreadVC.dll somewhere in the Windows PATH.

Now I'm trying to use tclkit and starkit to wrap my application
into a single executable (I have to send this thing to people
that wouldn't know how to install tcl).

The way starkit works is that it creates a virtual file system
in the executable file that corresponds to the one of the unwrapped
application. Whenever a tcl library (in the form of a dll) is required,
the starkit copies it to a temporary file, so that the system can see
and load it. Unfortunately this seems to work only with tcl libraries.

In my case my tcl lib relies on pthreadVC.dll, and there doesn't seem
to be a way to load it dynamically when it is wrapped in the starkit.

The only solution would be to distribute pthreadVC.dll separately and
instruct the users to put it somewhere in the path (which, given the
target users isn't likely to work).

Is there a way to link pthreadVC statically and avoid all these problems?

Thank you
Giampiero

Re: link statically

[Ross Johnson]

Have you tried FreeWrap? Does it have the same problem?

If you do statically link you may find it convenient to just compile and 
link the module pthread.c, which #includes all of the other relevant 
modules.

If you use static linking there are a couple of things that your 
application must do that are done for it automatically when using the 
DLL. It must make calls to the following routines as described below:

BOOL pthread_win32_process_attach_np(void)
BOOL pthread_win32_process_detach_np(void)
BOOL pthread_win32_thread_attach_np(void)
BOOL pthread_win32_thread_detach_np(void)

        These functions contain the code normally run via dllMain
        when the library is used as a dll but which need to be
        called explicitly by an application when the library
        is statically linked.

        You will need to call pthread_win32_process_attach_np() before
        you can call any pthread routines when statically linking.
        You should call pthread_win32_process_detach_np() before
        exiting your application to clean up.

        pthread_win32_thread_attach_np() is currently a no-op, but
        pthread_win32_thread_detach_np() is needed to clean up
        the implicit pthread handle that is allocated to a Win32 thread if
        it calls certain pthreads routines. Call this routine when the Win32
        thread exits.

        These functions invariably return TRUE except for
        pthread_win32_process_attach_np() which will return FALSE
        if pthreads-win32 initialisation fails.

Regards.
Ross

Giampiero Salvi wrote:

>Hi all,
>I've been using pthreads-win32 the develop a tcl library.
>Everything has been working fine, provided that I had the
>pthreadVC.dll somewhere in the Windows PATH.
>
>Now I'm trying to use tclkit and starkit to wrap my application
>into a single executable (I have to send this thing to people
>that wouldn't know how to install tcl).
>
>The way starkit works is that it creates a virtual file system
>in the executable file that corresponds to the one of the unwrapped
>application. Whenever a tcl library (in the form of a dll) is required,
>the starkit copies it to a temporary file, so that the system can see
>and load it. Unfortunately this seems to work only with tcl libraries.
>
>In my case my tcl lib relies on pthreadVC.dll, and there doesn't seem
>to be a way to load it dynamically when it is wrapped in the starkit.
>
>The only solution would be to distribute pthreadVC.dll separately and
>instruct the users to put it somewhere in the path (which, given the
>target users isn't likely to work).
>
>Is there a way to link pthreadVC statically and avoid all these problems?
>
>Thank you
>Giampiero
>  
>