feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

[Roger Pack]

would it be possible to somehow modify pthreads-win32 so that, if
compiled as static, and used as static, there is no need for the
"using" program to have to specify PTW32_STATIC_LIB ?  It seems a bit
odd to me to have to, for instance, configure ffmpeg like

./configure --extra-cflags=-DPTW32_STATIC_LIB

in order to be able to use it.
Anyway just thinking out loud.
Thanks!
-roger-

Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

[Ross Johnson]

Hi Roger,

Happy to receive suggestions that work for both MSVS and GNU toolchains. 
It must be possible (although I haven't found a way, but I'm probably 
overestimating the problem and just can't see the obvious). 
PTW32_STATIC_LIB is there during app builds because the headers 
(pthread.h, sched.h, semaphore.h) are used both in building the library 
and building apps but simply controls the export/import of symbols or not.

On 16/02/2013 5:36 AM, Roger Pack wrote:
> would it be possible to somehow modify pthreads-win32 so that, if
> compiled as static, and used as static, there is no need for the
> "using" program to have to specify PTW32_STATIC_LIB ?  It seems a bit
> odd to me to have to, for instance, configure ffmpeg like
>
> ./configure --extra-cflags=-DPTW32_STATIC_LIB
>
> in order to be able to use it.
> Anyway just thinking out loud.
> Thanks!
> -roger-

Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

[Roger Pack]

> Sounds like you wanted to address this to the list but I think you
> replied only to me.

oops, moving back on list...suggest the ML be modified so the default
reply-to is the ML :)

> In Linux, the usual 'static' qualifier on declarations controls
> visibility, regardless of dynamic or static linking but is restricted to
> a file (or perhaps more accurately a compilation unit). If this isn't
> convenient then GCC 4 and above recognise __attribute__
> ((visibility("hidden"))), and also "#pragma GCC visibility
> push(hidden)/#pragma GCC visibility pop" for block coverage in e.g.
> header files. Otherwise everything is visible by default.
>
> So I believe GNU can build a Windows dynamic or static library using the
> merged pthread.c after adding 'static' qualifiers where necessary, but I
> don't know off-hand if this works for MSVS. If it does, i.e. replace the
> need for _declspec(export/import), then we probably have a solution.

Yeah I know for FFmpeg they ended up basically "having" to use
_declspec at least for shared constants (for the rest I guess there
was some way around it, using their av_export symbol, but I'm no pro
here :)
I suppose the status quo is all right for now, thanks.
-roger-

Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

[Roger Pack]

On 2/20/13, Roger Pack <rogerdpack2@gmail.com> wrote:
>> Sounds like you wanted to address this to the list but I think you
>> replied only to me.
>
> oops, moving back on list...suggest the ML be modified so the default
> reply-to is the ML :)
>
>> In Linux, the usual 'static' qualifier on declarations controls
>> visibility, regardless of dynamic or static linking but is restricted to
>> a file (or perhaps more accurately a compilation unit). If this isn't
>> convenient then GCC 4 and above recognise __attribute__
>> ((visibility("hidden"))), and also "#pragma GCC visibility
>> push(hidden)/#pragma GCC visibility pop" for block coverage in e.g.
>> header files. Otherwise everything is visible by default.
>>
>> So I believe GNU can build a Windows dynamic or static library using the
>> merged pthread.c after adding 'static' qualifiers where necessary, but I
>> don't know off-hand if this works for MSVS. If it does, i.e. replace the
>> need for _declspec(export/import), then we probably have a solution.

I saw this the other day in a script that installs win32-pthreads:

for file in 'pthread.h' 'sched.h' 'semaphore.h'; do
  ed -s "$prefix/include/$file" <<< $'g/ __declspec (dllexport)/s///g\nw\nq'
  ed -s "$prefix/include/$file" <<< $'g/ __declspec (dllimport)/s///g\nw\nq'
done

I'll admit that it is a bit frustrating to have to do
 export CFLAGS=-DPTW32_STATIC_LIB
for anything that ends up using pthreads...

FWIW.
-roger-

Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ?

[Ross Johnson]

On 1/11/2013 6:46 AM, Roger Pack wrote:
> On 2/20/13, Roger Pack <rogerdpack2@gmail.com> wrote:
>>> Sounds like you wanted to address this to the list but I think you
>>> replied only to me.
>> oops, moving back on list...suggest the ML be modified so the default
>> reply-to is the ML :)
>>
>>> In Linux, the usual 'static' qualifier on declarations controls
>>> visibility, regardless of dynamic or static linking but is restricted to
>>> a file (or perhaps more accurately a compilation unit). If this isn't
>>> convenient then GCC 4 and above recognise __attribute__
>>> ((visibility("hidden"))), and also "#pragma GCC visibility
>>> push(hidden)/#pragma GCC visibility pop" for block coverage in e.g.
>>> header files. Otherwise everything is visible by default.
>>>
>>> So I believe GNU can build a Windows dynamic or static library using the
>>> merged pthread.c after adding 'static' qualifiers where necessary, but I
>>> don't know off-hand if this works for MSVS. If it does, i.e. replace the
>>> need for _declspec(export/import), then we probably have a solution.
> I saw this the other day in a script that installs win32-pthreads:
>
> for file in 'pthread.h' 'sched.h' 'semaphore.h'; do
>    ed -s "$prefix/include/$file" <<< $'g/ __declspec (dllexport)/s///g\nw\nq'
>    ed -s "$prefix/include/$file" <<< $'g/ __declspec (dllimport)/s///g\nw\nq'
> done
>
> I'll admit that it is a bit frustrating to have to do
>   export CFLAGS=-DPTW32_STATIC_LIB
> for anything that ends up using pthreads...
>
> FWIW.
> -roger-

The original intent was that the library would always be a DLL so the 
burden was placed on static link users to add the switch.

I don't like having references to linkage mode in header files but IIRC 
couldn't avoid it, so if anyone does have a way of avoiding it I'd be 
interested.