text: This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.
  Hi, Thanks for the changes and the explanations. They certainly fill a gap. On Wed, 2005-03-30 at 17:15 +0300, Dimitar Panayotov wrote: > Hello. > I show (as short as I can) a small note about statically > linking to the Pthreads-Win32 library. > > My deprecation: why using _DLL macro to determine whether > to link statically or dynamically? The PTW32_BUILD conditional was added by me. I've never built the library statically, and don't test this side of things. This is because the library is essentially designed for dynamic linking (although it can be static linked provided your app/dll does some extra things - see later). The _DLL conditional may have been contributed by someone who has statically linked the library, and it presumably worked for them. I don't recall adding it myself, but that's also possible - in which case I would have been blind to the implications you've described. > As you know, _DLL is > used by the Microsoft headers; when defined, it links your > app/lib/dll with an import library, which by itself points > to the dynamically linked libraries, containing > implementation of the C-Runtime Library on Win32. When _DLL > not defined, C-Runtime is linked statically into your > app/lib/dll. So, why the type of the linkage with the > C-Runtime is bound to the type of linkage with > Pthreads-Win32? This isn't deliberate, it just hasn't been an issue before. > In order to link my dll with Pthreads-Win32 statically, I > had to do some minor changes: > Please see the description of:- pthread_win32_process_attach_np () pthread_win32_process_detach_np () pthread_win32_thread_attach_np () pthread_win32_thread_detach_np () in README.NONPORABLE. You need to call these explicitly when static linking. Since your project is a dll, I assume you can just call them from your own dllMain(). > 1. Code in <pthread.h> which I altered: > > #ifdef _DLL > # ifdef PTW32_BUILD > # define PTW32_DLLPORT __declspec (dllexport) > # else > # define PTW32_DLLPORT __declspec (dllimport) > # endif > #endif > > with: > > #ifdef PTW32_DLL > # ifdef PTW32_BUILD > # define PTW32_DLLPORT __declspec (dllexport) > # else > # define PTW32_DLLPORT __declspec (dllimport) > # endif > #else > #define PTW32_DLLPORT > #endif > > You surely realize what I do: First, I use a separate macro > to determine whether to link statically or dynamically to > Pthreads-Win32. Second, if you not explicitly define > PTW32_DLLPORT as an empty macro, MSVC compiler expands it > to __declspec(dllimport), no matter of the fact, that the > preprocessor does not actually enter in the #ifdef > PTW32_DLL block!! It's so funny. Of course, I did not > wasted my time to check some strange implications which > could be made by the MSVC compiler, since it always knows > better than you what you actually want. :) > > 2. In <semaphore.h> and <sched.h> preprocessor code was > similar, with the difference that there were no #ifdef > _DLL. There I changed the code exactly as in <pthread.h> > > 3. In <pthread.c> I altered the following code: > > #include <dll.c> > > with: > > #ifdef PTW32_DLL > #include <dll.c> > #endif > > --- > > The result of all this is: when you do not define PTW32_DLL > in your build, you will be sure that Pthread-Win32 > function's declarations will not contain > __declspec(dllexport) / __declspec(dllimport). Also, when > you build your own DLL, you assure that no conflict will > occur with the Pthread-Win32's DllMain(). > > Sorry for the bad English, it's not my native language. > > Of course, one human does not need to be a genius to note > such things, nor will I pretend to be very smart for > writing this note. :) I just hope it to be useful. > > --------------------- > | Dimitar Panayotov | > | develop@mail.bg | > | +359886420488 | > --------------------- > > ----------------------------- > > "ÐÐÐÑÑÐÐÑÐÐ" - ÐÐÐÐ ÐÐÐÑÑÐÐÑÐÐ (ÐÐÐÐÑ ÐÐÐÐÑ) ÐÐÑÐ Ð ÐÐÐ Ð ÐÐÐ. > ÐÐÐ ÐÐÐ ÐÐÑÐÐÑÐ ÐÐ ÑÐÐÐÐÐÐÐÐÐ ÐÐÐÐÐÐÑÐ, ÐÑÐÐÐÐ ÑÐÐÐÑÐÐ ÐÐÐÐÐ. > >