From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28135 invoked by alias); 14 Aug 2003 16:24:31 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 28126 invoked from network); 14 Aug 2003 16:24:29 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by sources.redhat.com with SMTP; 14 Aug 2003 16:24:29 -0000 Received: from callisto.canberra.edu.au (special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.11.6/8.11.6) with ESMTP id h7EGNRj04396; Fri, 15 Aug 2003 02:23:44 +1000 Message-ID: <3F3BB772.8030503@callisto.canberra.edu.au> Date: Thu, 14 Aug 2003 16:24:00 -0000 From: Ross Johnson Reply-To: rpj@callisto.canberra.edu.au User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giampiero Salvi CC: pthreads-win32@sources.redhat.com Subject: Re: link statically References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00070.txt.bz2 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 > >