Static link (MSVC), alteration proposal

Static link (MSVC), alteration proposal

[Dimitar Panayotov]

 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? 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?

 In order to link my dll with Pthreads-Win32 statically, I
had to do some minor changes:

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     |
---------------------

-----------------------------

"Константин"  -  Джон Константин (Киану Рийвс) вече е бил в ада.
Той има дарбата да разпознава демоните, приели човешки облик.
http://www.mail.bg/info/?action=1200&title=%CA%EE%ED%F1%F2%E0%ED%F2%E8%ED%20%282005%29&date

Re: Static link (MSVC), alteration proposal

[Ross Johnson]

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     |
> ---------------------
> 
> -----------------------------
> 
> "Константин"  -  Джон Константин (Киану Рийвс) вече е бил в ада.
> Той има дарбата да разпознава демоните, приели човешки облик.
> http://www.mail.bg/info/?action=1200&title=%CA%EE%ED%F1%F2%E0%ED%F2%E8%ED%20%282005%29&date
> 

Re: Re: Static link (MSVC), alteration proposal

[Dimitar Panayotov]

> Hi,
> Thanks for the changes and the explanations. They
> certainly fill a gap.

Hello, Ross, and thank you for your detailed attention you
attested.

> 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

No, PTW32 is written very clever.

1. Since the sources are written in a way which relies on
the headers to determine the type of linkage of all the
PTW32 functions, then actually everything is up to the
headers.
2. Since all the sources are combined in single one --
<pthread.c>, things are quite easy, because you only need
to add <pthread.c> to your project (or give to it a
separate entry in the Makefile), it will be compiled, and
then pthread.obj will be included in the final link, and
that's it.

I admit that the style of the people who have written PTW32,
is professional.

> 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 ()

And thank you for pointing me to the functions which must be
used when statically linking with PTW32. I am aware of
those, but I forgot to mention them. Sorry.

Again, thank you for your attention. Respects.

-
Dimitar Panayotov
develop@mail.bg
+359886420488



--------------------------------------
Това писмо е изпратено от  www.mail.bg

Безплатната поща в mail.bg предлага:
- Силна защита срещу СПАМ/рекламни писма
- 30MB безплатно (SMS от 2лв=3GB!)
- 30MB макс. размер на прикачен файл
- SMS за ново писмо (всички оператори)
- WAP достъп от GSM и без компютър
- Безплатен POP3 достъп
- 24 часов телефон за помощ/поддръжка
______________________________________
БЕЗ ИЗЛИШНИ ВЪПРОСИ РЕГИСТРИРАЙТЕ СВОЙ
БЕЗПЛАТЕН АДРЕС НА  http://www.mail.bg

Re: Re: Static link (MSVC), alteration proposal

[Ross Johnson]

On Thu, 2005-03-31 at 10:42 +0300, Dimitar Panayotov wrote:
> > Hi,
> > Thanks for the changes and the explanations. They
> > certainly fill a gap.
> 
> Hello, Ross, and thank you for your detailed attention you
> attested.
> 
> > 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
> 
> No, PTW32 is written very clever.
> 

Much has been added or modified since John Bossom contributed his
original version of the library, but a fundamental design feature from
that version that has been kept is the ability of Win32 threads to call
POSIX routines, and thus become pseudo POSIX threads. This requires some
behind-the-scene work to manage, and it's important that cleaning up be
done when these threads exit, or the process exits. For this to be
seamless and transparent to an application that uses the library ideally
requires the dllMain feature.

> 1. Since the sources are written in a way which relies on
> the headers to determine the type of linkage of all the
> PTW32 functions, then actually everything is up to the
> headers.
> 2. Since all the sources are combined in single one --
> <pthread.c>, things are quite easy, because you only need
> to add <pthread.c> to your project (or give to it a
> separate entry in the Makefile), it will be compiled, and
> then pthread.obj will be included in the final link, and
> that's it.
> 
Yes, you can do that. This was how John's original version was
presented. Then I split the routines out into separate modules so that a
static library could be built such that any static linking exe could
include only those routines it needed (for embedded applications). But
apparently all of the target compilers include options to do this
automatically anyway. The monolithic pthread.c file is intended
primarily to reassemble all of the modules into a single compilation
unit in an attempt to maximise inlining of functions within the library.

> I admit that the style of the people who have written PTW32,
> is professional.

All of the contributions to the library have been absolutely awesome.

Regards.
Ross