Re: Static Library Initialization (again?)

["John E. Bossom" <drifting@pioneerwireless.ca>]

>> 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 <ramiro.polla@gmail.com>:

> Hi,
>
> On Tue, Jun 17, 2008 at 8:27 PM, Brian Cole <coleb2@gmail.com> 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
>