Static Library Initialization (again?)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Static Library Initialization (again?)

Brian Cole-4
It looks like I'm running into the same problem as others. I need to
distribute a static library with pthreads-win32 included without
requiring end-users of our library to call any pthreads-win32 specific
attach or detach code. Based on previous posts to the mailing list it
looks like the boost library has dealt with this before:
http://sourceware.org/ml/pthreads-win32/2008/msg00022.html

I also found this bit of code inside the Google performance tools:
#ifdef _MSC_VER

// This tells the linker to run these functions.
#pragma data_seg(push, old_seg)
#pragma data_seg(".CRT$XLB")
static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason, PVOID pv)
    = on_tls_callback;
#pragma data_seg(".CRT$XTU")
static int (*p_process_term)(void) = on_process_term;
#pragma data_seg(pop, old_seg)

#else  // #ifdef _MSC_VER  [probably msys/mingw]

// We have to try the DllMain solution here, because we can't use the
// msvc-specific pragmas.
<snipped for brevity>

#endif  // #ifdef _MSC_VER

Any reason pthreads-win32 can't use these same mechanisms to initialize itself?

Why can't DllMain be used for this? MSDN seems to imply that DllMain
is called for static libraries
(http://msdn.microsoft.com/en-us/library/ms682583.aspx):
"The lpReserved parameter indicates whether the DLL is being loaded
statically or dynamically."

I just looked through boost and found their implementation
(boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
creating a patch based on this code for pthreads-win32?

-Brian
Reply | Threaded
Open this post in threaded view
|

Re: Static Library Initialization (again?)

Ross Johnson-2
Brian Cole wrote:

> It looks like I'm running into the same problem as others. I need to
> distribute a static library with pthreads-win32 included without
> requiring end-users of our library to call any pthreads-win32 specific
> attach or detach code. Based on previous posts to the mailing list it
> looks like the boost library has dealt with this before:
> http://sourceware.org/ml/pthreads-win32/2008/msg00022.html
>
> I also found this bit of code inside the Google performance tools:
> #ifdef _MSC_VER
>
> // This tells the linker to run these functions.
> #pragma data_seg(push, old_seg)
> #pragma data_seg(".CRT$XLB")
> static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason, PVOID pv)
>     = on_tls_callback;
> #pragma data_seg(".CRT$XTU")
> static int (*p_process_term)(void) = on_process_term;
> #pragma data_seg(pop, old_seg)
>
> #else  // #ifdef _MSC_VER  [probably msys/mingw]
>
> // We have to try the DllMain solution here, because we can't use the
> // msvc-specific pragmas.
> <snipped for brevity>
>
> #endif  // #ifdef _MSC_VER
>
> Any reason pthreads-win32 can't use these same mechanisms to initialize itself?
>
> Why can't DllMain be used for this? MSDN seems to imply that DllMain
> is called for static libraries
> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
> "The lpReserved parameter indicates whether the DLL is being loaded
> statically or dynamically."
>
> I just looked through boost and found their implementation
> (boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
> creating a patch based on this code for pthreads-win32?
>  
A patch based on the Boost solution would be very welcome. It looks to
me like both Google and Boost are using the same technique but the Boost
version appears to include a version for Mingw32.

I'm not familiar with this enough to tell - does this solution work for
dynamic loading as well, or just static? I ask because there are a
couple of calls in DllMain that are forbidden according to the Microsoft
doco, such as calling LoadLibrary, but work anyway.

> -Brian
>  

Reply | Threaded
Open this post in threaded view
|

Re: Static Library Initialization (again?)

John Bossom
In reply to this post by Brian Cole-4
Quoting Brian Cole <[hidden email]>:

> Why can't DllMain be used for this? MSDN seems to imply that DllMain
> is called for static libraries
> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
> "The lpReserved parameter indicates whether the DLL is being loaded
> statically or dynamically."

You can statically link against the implib of a DLL or dynamically load
the DLL at run time. Regardless a DLL is a DLL is a DLL. That is
what they mean in MSDN... DllMain only exists for DLLs not static libraries.


Reply | Threaded
Open this post in threaded view
|

Re: Static Library Initialization (again?)

Ramiro Polla-3
In reply to this post by Brian Cole-4
Hi,

On Tue, Jun 17, 2008 at 8:27 PM, Brian Cole <[hidden email]> wrote:

> It looks like I'm running into the same problem as others. I need to
> distribute a static library with pthreads-win32 included without
> requiring end-users of our library to call any pthreads-win32 specific
> attach or detach code. Based on previous posts to the mailing list it
> looks like the boost library has dealt with this before:
> http://sourceware.org/ml/pthreads-win32/2008/msg00022.html
>
> I also found this bit of code inside the Google performance tools:
> #ifdef _MSC_VER
>
> // This tells the linker to run these functions.
> #pragma data_seg(push, old_seg)
> #pragma data_seg(".CRT$XLB")
> static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason, PVOID pv)
>    = on_tls_callback;
> #pragma data_seg(".CRT$XTU")
> static int (*p_process_term)(void) = on_process_term;
> #pragma data_seg(pop, old_seg)
>
> #else  // #ifdef _MSC_VER  [probably msys/mingw]
>
> // We have to try the DllMain solution here, because we can't use the
> // msvc-specific pragmas.
> <snipped for brevity>
>
> #endif  // #ifdef _MSC_VER
>
> Any reason pthreads-win32 can't use these same mechanisms to initialize itself?
>
> Why can't DllMain be used for this? MSDN seems to imply that DllMain
> is called for static libraries
> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
> "The lpReserved parameter indicates whether the DLL is being loaded
> statically or dynamically."
>
> I just looked through boost and found their implementation
> (boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
> creating a patch based on this code for pthreads-win32?
I attached an ugly but working patch for this. I haven't tested
building pthreads with MSVC but the initialization code worked on a
standalone test app.

I added a new make clean GC-autostatic to build the library.

make clean GC-static tests pass. I also tested a bit with FFmpeg (but
not extensively).

I'm sure it can be dramatically improved (comments, documentation,
stress test, etc), but as a start it's good enough.

Ramiro Polla

static_library_initialization.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Static Library Initialization (again?)

John Bossom
>> Why can't DllMain be used for this? MSDN seems to imply that DllMain
>> is called for static libraries
>> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
>> "The lpReserved parameter indicates whether the DLL is being loaded
>> statically or dynamically."

There are two ways you can use a "dynamic library" (i.e. DLL)...
Statically link against it's implib and let the loader load it's DLL,
or programmatically by name.
This has nothing to do with an actual "static library" which is what this
topic is about.

Second, please beware that simply taking solutions from other open  
source components has the potential to taint the intellectual property  
rights of this open source component. open source doesn't mean free to  
copy... both Google and Boost are released under license and use of  
their code is subject to their respective license terms.
pthreads-win32 had chosen to release under the LGPL in order to permit  
use by commercial software in addition to open source projects.  
However, commercial companies can come under fire for using open  
source components with questionable lineage. Some commercial companies  
will not touch an open source component if the maintainer does not  
maintain a list of all contributors and can prove the code base is not  
tainted.

Respectfully,

John E. Bossom



Quoting Ramiro Polla <[hidden email]>:

> Hi,
>
> On Tue, Jun 17, 2008 at 8:27 PM, Brian Cole <[hidden email]> wrote:
>> It looks like I'm running into the same problem as others. I need to
>> distribute a static library with pthreads-win32 included without
>> requiring end-users of our library to call any pthreads-win32 specific
>> attach or detach code. Based on previous posts to the mailing list it
>> looks like the boost library has dealt with this before:
>> http://sourceware.org/ml/pthreads-win32/2008/msg00022.html
>>
>> I also found this bit of code inside the Google performance tools:
>> #ifdef _MSC_VER
>>
>> // This tells the linker to run these functions.
>> #pragma data_seg(push, old_seg)
>> #pragma data_seg(".CRT$XLB")
>> static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason,  
>>  PVOID pv)
>>    = on_tls_callback;
>> #pragma data_seg(".CRT$XTU")
>> static int (*p_process_term)(void) = on_process_term;
>> #pragma data_seg(pop, old_seg)
>>
>> #else  // #ifdef _MSC_VER  [probably msys/mingw]
>>
>> // We have to try the DllMain solution here, because we can't use the
>> // msvc-specific pragmas.
>> <snipped for brevity>
>>
>> #endif  // #ifdef _MSC_VER
>>
>> Any reason pthreads-win32 can't use these same mechanisms to  
>> initialize itself?
>>
>> Why can't DllMain be used for this? MSDN seems to imply that DllMain
>> is called for static libraries
>> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
>> "The lpReserved parameter indicates whether the DLL is being loaded
>> statically or dynamically."
>>
>> I just looked through boost and found their implementation
>> (boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
>> creating a patch based on this code for pthreads-win32?
>
> I attached an ugly but working patch for this. I haven't tested
> building pthreads with MSVC but the initialization code worked on a
> standalone test app.
>
> I added a new make clean GC-autostatic to build the library.
>
> make clean GC-static tests pass. I also tested a bit with FFmpeg (but
> not extensively).
>
> I'm sure it can be dramatically improved (comments, documentation,
> stress test, etc), but as a start it's good enough.
>
> Ramiro Polla
>


Reply | Threaded
Open this post in threaded view
|

Re: Static Library Initialization (again?)

Ramiro Polla-3
In reply to this post by Ramiro Polla-3
Hi,

On Thu, May 21, 2009 at 9:08 PM, Ramiro Polla<[hidden email]> wrote:

> On Tue, Jun 17, 2008 at 8:27 PM, Brian Cole <[hidden email]> wrote:
>> It looks like I'm running into the same problem as others. I need to
>> distribute a static library with pthreads-win32 included without
>> requiring end-users of our library to call any pthreads-win32 specific
>> attach or detach code. Based on previous posts to the mailing list it
>> looks like the boost library has dealt with this before:
>> http://sourceware.org/ml/pthreads-win32/2008/msg00022.html
>>
>> I also found this bit of code inside the Google performance tools:
>> #ifdef _MSC_VER
>>
>> // This tells the linker to run these functions.
>> #pragma data_seg(push, old_seg)
>> #pragma data_seg(".CRT$XLB")
>> static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason, PVOID pv)
>>    = on_tls_callback;
>> #pragma data_seg(".CRT$XTU")
>> static int (*p_process_term)(void) = on_process_term;
>> #pragma data_seg(pop, old_seg)
>>
>> #else  // #ifdef _MSC_VER  [probably msys/mingw]
>>
>> // We have to try the DllMain solution here, because we can't use the
>> // msvc-specific pragmas.
>> <snipped for brevity>
>>
>> #endif  // #ifdef _MSC_VER
>>
>> Any reason pthreads-win32 can't use these same mechanisms to initialize itself?
>>
>> Why can't DllMain be used for this? MSDN seems to imply that DllMain
>> is called for static libraries
>> (http://msdn.microsoft.com/en-us/library/ms682583.aspx):
>> "The lpReserved parameter indicates whether the DLL is being loaded
>> statically or dynamically."
>>
>> I just looked through boost and found their implementation
>> (boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
>> creating a patch based on this code for pthreads-win32?
>
> I attached an ugly but working patch for this. I haven't tested
> building pthreads with MSVC but the initialization code worked on a
> standalone test app.
>
> I added a new make clean GC-autostatic to build the library.
>
> make clean GC-static tests pass. I also tested a bit with FFmpeg (but
> not extensively).
>
> I'm sure it can be dramatically improved (comments, documentation,
> stress test, etc), but as a start it's good enough.

For some reason I didn't get John E. Bossom's reply in my inbox, so
I'm quoting it here:

> Second, please beware that simply taking solutions from other open
> source components has the potential to taint the intellectual property
> rights of this open source component. open source doesn't mean free to
> copy... both Google and Boost are released under license and use of
> their code is subject to their respective license terms.
> pthreads-win32 had chosen to release under the LGPL in order to permit
> use by commercial software in addition to open source projects.
> However, commercial companies can come under fire for using open
> source components with questionable lineage. Some commercial companies
> will not touch an open source component if the maintainer does not
> maintain a list of all contributors and can prove the code base is not
> tainted.

I used boost as a reference:
https://svn.boost.org/trac/boost/browser/trunk/libs/thread/src/win32/tss_pe.cpp

The header reads:
// (C) Copyright Aaron W. LaFramboise, Roland Schwarz, Michael Glassford 2004.
// (C) Copyright 2007 Roland Schwarz
// (C) Copyright 2007 Anthony Williams
// (C) Copyright 2007 David Deakins
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

The FSF affirms the boost license is GPL compatible, and from my
interpretation of the boost license, it is also LGPL compatible.

Whatever code is mine in that patch I license it as wtfpl <
http://sam.zoy.org/wtfpl/ >.

Ramiro Polla