public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@callisto.canberra.edu.au>
To: Pthreads-Win32 list <pthreads-win32@sources.redhat.com>
Subject: Re: Static link (MSVC), alteration proposal
Date: Wed, 30 Mar 2005 23:49:00 -0000	[thread overview]
Message-ID: <1112226518.19990.69.camel@desk.home> (raw)
In-Reply-To: <1112192108.9a7b65f2515a2@mail.bg>

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
> 

  reply	other threads:[~2005-03-30 23:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30 14:15 Dimitar Panayotov
2005-03-30 23:49 ` Ross Johnson [this message]
2005-03-31  7:42   ` Dimitar Panayotov
2005-03-31  8:29     ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1112226518.19990.69.camel@desk.home \
    --to=rpj@callisto.canberra.edu.au \
    --cc=pthreads-win32@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).