This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Static Library Initialization (again?)
- From: Ramiro Polla <ramiro dot polla at gmail dot com>
- To: pthreads-win32 at sourceware dot org
- Date: Sun, 7 Jun 2009 20:39:37 -0300
- Subject: Re: Static Library Initialization (again?)
- References: <firstname.lastname@example.org> <email@example.com>
On Thu, May 21, 2009 at 9:08 PM, Ramiro Polla<firstname.lastname@example.org> wrote:
> On Tue, Jun 17, 2008 at 8:27 PM, Brian Cole <email@example.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:
>> 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
>> "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
I used boost as a reference:
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 <