* feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? @ 2013-02-15 18:36 Roger Pack 2013-02-19 1:03 ` Ross Johnson 0 siblings, 1 reply; 5+ messages in thread From: Roger Pack @ 2013-02-15 18:36 UTC (permalink / raw) To: pthreads-win32 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- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? 2013-02-15 18:36 feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? Roger Pack @ 2013-02-19 1:03 ` Ross Johnson [not found] ` <CAL1QdWcyU76396H_RzXNBMAf7QFrmtC_Ab7ajC=TzG43QJm7fQ@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Ross Johnson @ 2013-02-19 1:03 UTC (permalink / raw) To: pthreads-win32 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- ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAL1QdWcyU76396H_RzXNBMAf7QFrmtC_Ab7ajC=TzG43QJm7fQ@mail.gmail.com>]
[parent not found: <51242375.1070904@homemail.com.au>]
* Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? [not found] ` <51242375.1070904@homemail.com.au> @ 2013-02-20 17:01 ` Roger Pack 2013-10-31 19:46 ` Roger Pack 0 siblings, 1 reply; 5+ messages in thread From: Roger Pack @ 2013-02-20 17:01 UTC (permalink / raw) To: Ross Johnson; +Cc: pthreads-win32 > 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- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? 2013-02-20 17:01 ` Roger Pack @ 2013-10-31 19:46 ` Roger Pack 2013-11-01 0:56 ` Ross Johnson 0 siblings, 1 reply; 5+ messages in thread From: Roger Pack @ 2013-10-31 19:46 UTC (permalink / raw) To: Ross Johnson; +Cc: pthreads-win32 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- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? 2013-10-31 19:46 ` Roger Pack @ 2013-11-01 0:56 ` Ross Johnson 0 siblings, 0 replies; 5+ messages in thread From: Ross Johnson @ 2013-11-01 0:56 UTC (permalink / raw) To: pthreads-win32 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-11-01 0:56 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-15 18:36 feature request: not need to specify PTW32_STATIC_LIB for static usage possible ? Roger Pack 2013-02-19 1:03 ` Ross Johnson [not found] ` <CAL1QdWcyU76396H_RzXNBMAf7QFrmtC_Ab7ajC=TzG43QJm7fQ@mail.gmail.com> [not found] ` <51242375.1070904@homemail.com.au> 2013-02-20 17:01 ` Roger Pack 2013-10-31 19:46 ` Roger Pack 2013-11-01 0:56 ` Ross Johnson
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).