From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18492 invoked by alias); 12 Apr 2005 16:26:51 -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 18347 invoked from network); 12 Apr 2005 16:26:42 -0000 Received: from unknown (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org with SMTP; 12 Apr 2005 16:26:42 -0000 Received: from [203.129.47.242] (helo=ppp-47-242.grapevine.net.au) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1DLNaU-0006nZ-00 for ; Wed, 13 Apr 2005 01:46:02 +1000 Subject: Re: static link last build issue & question From: Ross Johnson To: Pthreads-Win32 list In-Reply-To: <1113319690.fae3b25d4c132@mail.bg> References: <1113319690.fae3b25d4c132@mail.bg> Content-Type: text/plain; charset=UTF-8 Date: Tue, 12 Apr 2005 16:26:00 -0000 Message-Id: <1113320760.5350.53.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2005/txt/msg00067.txt.bz2 On Tue, 2005-04-12 at 18:28 +0300, Dimitar Panayotov wrote: > 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? Hi, I didn't miss it. I just did it another way. The dll.c module is included in the build but the entire content of dll.c is skipped when building the static library. I thought it would be better to excise the code itself. Is that causing a problem for you? > 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: >=20 > #include "dll.c" >=20 > the code must be: >=20 > #ifndef PTW32_STATIC_LIB > #include "dll.c" > #endif >=20 > 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.) >=20 > 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: >=20 > 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? It should be safe to call phread_win32_thread_detach_np() even if no POSIX routines have been called. For instance, I imagine, since you're project is a dll, you could call these attach/detach routines from your own dllMain switch. > Thank you. >=20 > - > Dimitar Panayotov > develop@mail.bg > +359886420488 >=20 >=20 > -------------------------------------- > =D0=91=D0=B5=D0=B7=D0=BF=D0=BB=D0=B0=D1=82=D0=BD=D0=B0=D1=82=D0=B0 =D0=BF= =D0=BE=D1=89=D0=B0 =D0=B2 mail.bg =D0=B2=D0=B5=D1=87=D0=B5 =D0=B5 1GB! >=20 >=20