From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19931 invoked by alias); 12 Apr 2005 15:28:35 -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 19462 invoked from network); 12 Apr 2005 15:28:26 -0000 Received: from unknown (HELO mx1.mail.bg) (193.201.172.114) by sourceware.org with SMTP; 12 Apr 2005 15:28:26 -0000 Received: from localhost (web1.mail.bg [193.201.172.98]) by mx1.mail.bg (Postfix) with ESMTP id 7970D72B6289 for ; Tue, 12 Apr 2005 18:28:10 +0300 (EEST) Received: from sun.fadata.bg (sun.fadata.bg [213.240.249.67]) by mail.bg (mail.bG Webmail 4.0.1) with HTTP for ; Tue, 12 Apr 2005 18:28:10 +0300 Message-ID: <1113319690.fae3b25d4c132@mail.bg> Date: Tue, 12 Apr 2005 15:28:00 -0000 From: Dimitar Panayotov To: pthreads-win32@sources.redhat.com Subject: static link last build issue & question MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: mail.bG Webmail 4.0-cvs X-SW-Source: 2005/txt/msg00066.txt.bz2 Hello. I guess you have much more important issues to solve in PTW32, but may I remind of one small alteration, which seem to be not spotted in my preceding post? When linking statically, must not be included in since it is possible you to build a DLL which you want to be statically linked to PTW32, in which case your DllMain() will conflict with the PTW32's DllMain(). So, in , instead of: #include "dll.c" the code must be: #ifndef PTW32_STATIC_LIB #include "dll.c" #endif This will avoid link-time error I mentioned above. (Note that the static link method I use is to include in my project or in the Makefile so that it will be built with the PTW32_STATIC_LIB macro being defined, and the object file -- included in the final link.) And, because of the obscurity of the statement [pthread_win32_thread_attach_np() is currently a no-op, but thread_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] (found in README.NONPORTABLE), I have the following questions: Can we be supplied with a list of those routines, calling of which will make it compulsory for the WIN32 thread to call "pthread_win32_thread_detach_np()" when it exits? And, if not, is it safe always to call "pthread_win32_thread_detach_np()" even if no PTW32 API is used in it? Thank you. - Dimitar Panayotov develop@mail.bg +359886420488 -------------------------------------- =C1=E5=E7=EF=EB=E0=F2=ED=E0=F2=E0 =EF=EE=F9=E0 =E2 mail.bg =E2=E5=F7=E5 =E5= 1GB!