Quantcast

enable std::thread experimental patch

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

enable std::thread experimental patch

xunxun
Hi, all

     I have successfully built mingw64 gcc4.6.2 prerelease with
std::thread using posix thread modal.
     I test the code, and this works:
-----------------------------------------------------
#include <iostream>
#include <thread>
void thanks()
{
     std::cout << "Thank you for your reading.\n";
};
int main()
{
     std::thread t( thanks );
     t.join();
     return 0;
}
------------------------------------------------------

     Here is my patch:
------------------------------------------------------
diff -ruNa old/gcc/config/i386/mingw32.h build/gcc/config/i386/mingw32.h
--- old/gcc/config/i386/mingw32.h    2010-09-30 02:55:44 +0800
+++ build/gcc/config/i386/mingw32.h    2011-08-27 19:14:57 +0800
@@ -114,7 +114,7 @@
  #define REAL_LIBGCC_SPEC \
    "%{mthreads:-lmingwthrd} -lmingw32 \
     "SHARED_LIBGCC_SPEC" \
-   -lgcc \
+   -lgcc -lpthread \
     -lmoldname -lmingwex -lmsvcrt"

  #undef STARTFILE_SPEC
@@ -169,7 +169,8 @@

  /* mingw32 uses the  -mthreads option to enable thread support.  */
  #undef GOMP_SELF_SPECS
-#define GOMP_SELF_SPECS "%{fopenmp: -mthreads}"
+#define GOMP_SELF_SPECS "%{fopenmp|ftree-parallelize-loops=*: " \
+                       "-mthreads -lpthread}"

  /* mingw32 atexit function is safe to use in shared libraries.  Use it
     to register C++ static destructors.  */
diff -ruNa old/gcc/gthr-posix.h build/gcc/gthr-posix.h
--- old/gcc/gthr-posix.h    2011-01-04 04:52:22 +0800
+++ build/gcc/gthr-posix.h    2011-08-27 22:19:16 +0800
@@ -32,6 +32,7 @@

  #define __GTHREADS 1
  #define __GTHREADS_CXX0X 1
+#define _POSIX_TIMEOUTS 1

  /* Some implementations of <pthread.h> require this to be defined.  */
  #if !defined(_REENTRANT) && defined(__osf__)
diff -ruNa old/gcc/gthr.h build/gcc/gthr.h
--- old/gcc/gthr.h    2009-11-25 18:55:54 +0800
+++ build/gcc/gthr.h    2011-08-27 22:19:41 +0800
@@ -30,6 +30,10 @@
  #pragma GCC visibility push(default)
  #endif

+#define __GTHREADS 1
+#define __GTHREADS_CXX0X 1
+#define _POSIX_TIMEOUTS 1
+
  /* If this file is compiled with threads support, it must
         #define __GTHREADS 1
     to indicate that threads support is present.  Also it has define
diff -ruNa old/libstdc++-v3/config/os/mingw32/error_constants.h
build/libstdc++-v3/config/os/mingw32/error_constants.h
--- old/libstdc++-v3/config/os/mingw32/error_constants.h    2011-01-31
06:39:36 +0800
+++ build/libstdc++-v3/config/os/mingw32/error_constants.h    2011-08-27
23:58:11 +0800
@@ -99,7 +99,7 @@
  //    not_supported =                 ENOTSUP,
  //    operation_canceled =             ECANCELED,
  //    operation_in_progress =             EINPROGRESS,
-//    operation_not_permitted =         EPERM,
+      operation_not_permitted =         EPERM,
  //    operation_not_supported =         EOPNOTSUPP,
  //    operation_would_block =             EWOULDBLOCK,
  //    owner_dead =                 EOWNERDEAD,
--------------------------------------------------------------------------

     You must configure gcc with "--enable-threads=posix", and should
use Kai's winpthreads.

      winpthreads svn :
https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads

     Here is the test gcc package:

http://pcxprj.googlecode.com/files/MinGW_gcc4.6.2.20110826_static_enable_std_thread_test.7z 


--
Best Regards,
PcX


------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

thread.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Charles Wilson-2
On 8/28/2011 1:09 AM, PcX wrote:
>     You must configure gcc with "--enable-threads=posix", and should use
> Kai's winpthreads.
>
>      winpthreads svn :
> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads

I'm curious: what's the rationale for the new winpthreads package, vs.
the existing pthreads-win32 project?
http://sourceware.org/pthreads-win32/

Is it a 64bit issue, or is there some other problem with pthreads-win32
(or the fact it hasn't published an official release since 2006,
although CVS shows some more recent activity)?  Kai's not known for
doing stuff "just because" so I assume there's a reason...

--
Chuck


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

JonY-3
On 8/30/2011 04:26, Charles Wilson wrote:

> On 8/28/2011 1:09 AM, PcX wrote:
>>     You must configure gcc with "--enable-threads=posix", and should use
>> Kai's winpthreads.
>>
>>      winpthreads svn :
>> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads
>
> I'm curious: what's the rationale for the new winpthreads package, vs.
> the existing pthreads-win32 project?
> http://sourceware.org/pthreads-win32/
>
> Is it a 64bit issue, or is there some other problem with pthreads-win32
> (or the fact it hasn't published an official release since 2006,
> although CVS shows some more recent activity)?  Kai's not known for
> doing stuff "just because" so I assume there's a reason...
>
iirc winpthreads started because pthreads-win32 was slow to accept any
patches sent their way, email conversations tend to drop off for some
reason.

Kai also wanted pthread_t to be a scalar instead of a structure, so it
will work with programs that bad assumptions about it.



------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Kai Tietz-2
2011/8/30 JonY <[hidden email]>:

> On 8/30/2011 04:26, Charles Wilson wrote:
>> On 8/28/2011 1:09 AM, PcX wrote:
>>>     You must configure gcc with "--enable-threads=posix", and should use
>>> Kai's winpthreads.
>>>
>>>      winpthreads svn :
>>> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads
>>
>> I'm curious: what's the rationale for the new winpthreads package, vs.
>> the existing pthreads-win32 project?
>> http://sourceware.org/pthreads-win32/
>>
>> Is it a 64bit issue, or is there some other problem with pthreads-win32
>> (or the fact it hasn't published an official release since 2006,
>> although CVS shows some more recent activity)?  Kai's not known for
>> doing stuff "just because" so I assume there's a reason...
>>
>
> iirc winpthreads started because pthreads-win32 was slow to accept any
> patches sent their way, email conversations tend to drop off for some
> reason.
>
> Kai also wanted pthread_t to be a scalar instead of a structure, so it
> will work with programs that bad assumptions about it.

As Jon_Y said,  first cause for this winpthread was to have a pthread
implementation, which provides better supports for 64-bit (but also
for 32-bit) specific Windows version.
Next item is that it gets supported by existing pthread-related code
in some gnu-software, like libgomp, obj-c, etc.  A lot of ventures are
assuming that pthread_t is a scalar-valued type, and not a structure.
I know that specification allows a structure-definition of pthread_t,
but nevertheless it isn't supported by much user-source code.
Next point about winpthread is that it utilizes TLS callback for a
better and more reliable way to cleanup thread-data.
Also it implements some locking stuff (like spins, conditions, and
barriers in slightly different way, so that it supports some new
features and more compatible behavior to *NIX-version for pthread-API.
For sure it is all but complete, but already working nice.  One point
I see so far is, that I think to add some of the missing error-numbers
for socket-types via their WSA-constants.  This needs to be done in
errno.h (and pthread.h for backward compatiblity).  I will come to
this point after my holiday.

Kai

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Kai Tietz-2
2011/8/30 Kai Tietz <[hidden email]>:

> 2011/8/30 JonY <[hidden email]>:
>> On 8/30/2011 04:26, Charles Wilson wrote:
>>> On 8/28/2011 1:09 AM, PcX wrote:
>>>>     You must configure gcc with "--enable-threads=posix", and should use
>>>> Kai's winpthreads.
>>>>
>>>>      winpthreads svn :
>>>> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads
>>>
>>> I'm curious: what's the rationale for the new winpthreads package, vs.
>>> the existing pthreads-win32 project?
>>> http://sourceware.org/pthreads-win32/
>>>
>>> Is it a 64bit issue, or is there some other problem with pthreads-win32
>>> (or the fact it hasn't published an official release since 2006,
>>> although CVS shows some more recent activity)?  Kai's not known for
>>> doing stuff "just because" so I assume there's a reason...
>>>
>>
>> iirc winpthreads started because pthreads-win32 was slow to accept any
>> patches sent their way, email conversations tend to drop off for some
>> reason.
>>
>> Kai also wanted pthread_t to be a scalar instead of a structure, so it
>> will work with programs that bad assumptions about it.
>
> As Jon_Y said,  first cause for this winpthread was to have a pthread
> implementation, which provides better supports for 64-bit (but also
> for 32-bit) specific Windows version.
> Next item is that it gets supported by existing pthread-related code
> in some gnu-software, like libgomp, obj-c, etc.  A lot of ventures are
> assuming that pthread_t is a scalar-valued type, and not a structure.
> I know that specification allows a structure-definition of pthread_t,
> but nevertheless it isn't supported by much user-source code.
> Next point about winpthread is that it utilizes TLS callback for a
> better and more reliable way to cleanup thread-data.
> Also it implements some locking stuff (like spins, conditions, and
> barriers in slightly different way, so that it supports some new
> features and more compatible behavior to *NIX-version for pthread-API.
> For sure it is all but complete, but already working nice.  One point
> I see so far is, that I think to add some of the missing error-numbers
> for socket-types via their WSA-constants.  This needs to be done in
> errno.h (and pthread.h for backward compatiblity).  I will come to
> this point after my holiday.
>
> Kai

Ah, another point I missed to mention.  We need to provide for
winpthread an installation to our header-set and I we need to plan how
we can make it a fixed-feature of our crt-runtime system.  As we need
to have an indicator for unistd.h to tell, if (and what) POSX-API is
supported by installation.  We could add to gcc's spec-file an
macro-name, which provides information about used threading-model, but
nevertheless we need to know if pthread-library is present too.  So I
plan to add an internal header, which gets overriden for such
information by winpthread-installation, describing necessary and
supported _POSIX... macros.

Best would be to support shared version of winpthread also for static
library of it.  So that multiple-versions within one application (in
EXE and/or DLLs) are using just one instance for this API.  This point
might be the most tricky one,  as we need to use here
environment-variable or named-shared memory to share necessary
pointers.   I haven't made up my mind for now, what kind of
implementation we should use here,  but this would increase
compatiblity to *nix-world pretty much.

Kai

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

K. Frank
Hello Lists!

On Tue, Aug 30, 2011 at 4:05 AM, Kai Tietz wrote:

> ...
>>> On 8/30/2011 04:26, Charles Wilson wrote:
>>>> ...
>>>> I'm curious: what's the rationale for the new winpthreads package, vs.
>>>> the existing pthreads-win32 project?
>>>> http://sourceware.org/pthreads-win32/
>>>>
>>>> Is it a 64bit issue, or is there some other problem with pthreads-win32
>>>> (or the fact it hasn't published an official release since 2006,
>>>> although CVS shows some more recent activity)?  Kai's not known for
>>>> doing stuff "just because" so I assume there's a reason...
>>> ...
>>> iirc winpthreads started because pthreads-win32 was slow to accept any
>>> patches sent their way, email conversations tend to drop off for some
>>> reason.
>>> ...
> Kai

Wasn't there also some licensing issue?  I never understood the details, but
I recall seeing warnings, perhaps on one of these lists, that the pthreads-win32
license was not as liberal as that of mingw / mingw-w64, and that there were
things I couldn't use it for.

If there are things that I can do with mingw / mingw-w64 that I can't do with
pthreads-win32, have those restrictions been relaxed with winpthreads?

Thanks.


K. Frank

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Charles Wilson-2
On 8/31/2011 5:39 PM, K. Frank wrote:
> Wasn't there also some licensing issue?  I never understood the details, but
> I recall seeing warnings, perhaps on one of these lists, that the pthreads-win32
> license was not as liberal as that of mingw / mingw-w64, and that there were
> things I couldn't use it for.
>
> If there are things that I can do with mingw / mingw-w64 that I can't do with
> pthreads-win32, have those restrictions been relaxed with winpthreads?

pthreads-win32 is LGPL.

Most libs ***that are an intrinsic part of the mingw.org compiler*** are
either public domain (libmingwex, e.g. no restrictions imposed on
compiled programs) or GPL-with-linking-exception (libgcc_s, libstdc++ --
e.g. no restrictions imposed on compiled programs).  This is true
whether you link statically or dynamically.  Assuming you
        1) don't link to OTHER libraries with copyleft or viral terms,
           and that themselves don't require source redist, and
        2) your app doesn't have licensing terms requiring source redist
you can ship to your clients a binary copy of your app and the DLLs that
it links to, without worrying about GPLishness or shipping source code.

However, the LGPL pthreads library is an issue.  (A) If you ship that
dll, you also have to be able to provide the source code *for that copy
of the pthreads-win32 dll*.  (B) Opinions vary, but some people claim
that if you link *statically* against an LGPL library, then the LGPL
becomes just as "viral" as the GPL -- and you have to distribute the
source code of your application.


Kai's winpthreads is partly MIT/X and partly (mostly?) 3-clause BSD. So,
"permissive" licensing.  Licensing wise, this is clearly a better fit
for mingw.org as well as mingw64.

--
Chuck


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Earnie Boyd
Charles Wilson wrote:
> However, the LGPL pthreads library is an issue.  (A) If you ship that
> dll, you also have to be able to provide the source code *for that copy
> of the pthreads-win32 dll*.  (B) Opinions vary, but some people claim
> that if you link *statically* against an LGPL library, then the LGPL
> becomes just as "viral" as the GPL -- and you have to distribute the
> source code of your application.

I don't really want to start a debate here but I always considered it to
be the other way round.  LGPL static, no need to ship source for the
library but ship LGPL dynamic libraries and you need to also ship the
source for the library.  If you distribute a binary whose source is
covered by L/GPL then you must be willing to distribute the source of
the binary.  The L(esser) part only allows the person using the library
to be free to have a differing license for the program using the
library.  It in no way lessens the burden of responsibility for source
distribution.  However, since this differing license doesn't require
source distribution, if I link to the library in static method, I don't
need to ship its source.  That same library in shared method, I need to
ship the source for the library if I distribute the binary for the
library.  This is the reason GNU.ORG encourages library licenses to be
GPL instead of LGPL.

--
Earnie (IANAL)
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Charles Wilson-2
On 9/1/2011 9:02 AM, Earnie wrote:

> Charles Wilson wrote:
>> However, the LGPL pthreads library is an issue.  (A) If you ship that
>> dll, you also have to be able to provide the source code *for that copy
>> of the pthreads-win32 dll*.  (B) Opinions vary, but some people claim
>> that if you link *statically* against an LGPL library, then the LGPL
>> becomes just as "viral" as the GPL -- and you have to distribute the
>> source code of your application.
>
> I don't really want to start a debate here but I always considered it to
> be the other way round.

I'm just telling you what my company's lawyers said -- and others, as
well. For proprietary products, we're allowed to use LGPL libs *so long
as* we only link dynamically.  Then, we're on the hook for providing the
source for that library and any modifications to it; but our other IP is
still "safe".  Statically linked...well, don't do that or I'd be looking
for another job after giving away multiple million $ in IP. (I don't
agree with their interpretation, I don't see how the manner of linking
makes any difference at all -- but them's the rules, and they are the
<s>scum sucking vampires</s>lawyers, not me.

--
Chuck



------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: enable std::thread experimental patch

Charles Wilson-2
In reply to this post by Charles Wilson-2
Preface: this whole discussion REALLY boils down to: IANAL, YANAL, so
nobody needs to listen to either one of us (but the folks who wrote the
GPL FAQ *are* lawyers, so we should probably listen to them). Also, seek
competent counsel and pay for your own analysis of the licenses, if this
is a business-critical need for you.



On 9/1/2011 3:27 AM, Prof Brian Ripley wrote:
> Are you an authority on licensing?

I'm the guy who invented the unpronounceable acronym
http://www.cygwin.com/acronyms/#YANALATEYHSMBSI

So, no, I'm not a laywer, thank god -- and if I was, I probably wouldn't
be giving out free legal analysis on a mailing list (no billable hours).
 Nor did I stay at a Holiday Inn last night -- but I have studied the
issue quite a bit, over the 15 or 20 years I've been involved in the
Free Software movement.  And read what a lot of real lawyers say about
it, including the ones who work for the FSF, and the ones at my company.

Everybody should, slowly and carefully, read the GPL FAQ; it will answer
most questions: http://www.gnu.org/licenses/gpl-faq.html

> I ask because others have posted
> contrary opinions when asked for clarification by a Mingw.org
> developer on the gcc lists: see the thread starting
>
> http://gcc.gnu.org/ml/gcc/2004-06/msg01123.html

That thread is about the *runtime libraries* that are part of gcc itself
-- as you mention below, the libgcc_s*.dll (or libgcc.a), libstdc++*.dll
(or .a), libgfortran*.dll (or .a), etc. [*]

THOSE libraries are "GPL-with-linking-exception", not LGPL or "pure"
GPL.  That *exception* is why you don't have to ship THEIR sources (NOR
your own app's sources) even if you link against them ("pure" GPL would
require you to ship both YOUR sources and THEIR sources; the "exception"
requires you only to ship THEIR sources **IF** you have modified them;
but your own app is not "virally infected")

If I understand correctly, if (say) mingw64 has modified libstdc++, then
they must provide their modified sources with the modified dll. But if I
simply USE that modified libstdc++ as part of a compilation, and don't
change the library, then I can treat it just like I would if it came
from the FSF unmodified: I can (re)distribute that DLL with my apps
without worrying about the DLL's source code (or (re)distribute an exe
that includes bits of the static libstdc++).  But that's only for
libraries that are "GPL-with-linking-exception", which pthreads-win32 is
not.

[*] pthreads-win32 is NOT part of gcc; it is an external lib USED by gcc
to provide threading support on win32.  mingw.org ships a copy of it
with our gcc, but that doesn't make it part of gcc or force gcc's
GPL-with-linking-exception license to apply to it.  It has its own
license -- which happens to be LGPL.

>> However, the LGPL pthreads library is an issue.  (A) If you ship that
>> dll, you also have to be able to provide the source code *for that copy
>> of the pthreads-win32 dll*.
>
> Many have expresed the opinion that is no different from the cases of
> libgcc_s.dll, libgfortran.dll and libstdc++.dll.

"Many". Are they lawyers? Did they consult lawyers or the statements of
lawyers (e.g. the gpl faq)?  Did they back it up by quoting parts of the
GPL license in question?

> Indeed, the relevant exception seems to be
> http://www.gnu.org/licenses/gcc-exception.html
> and I see nothing there which removes the obligation to supply sources
> for those DLLs if you ship them: it only applies to 'Target Code'
> (which does seem to include static linking against these).

"You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes.  You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules."

Combination: e.g. your app + the libstdc++ dll, or your app (with the
included libstdc++.a) bits. (definition included in your link)

Independent Modules: your code (again, definition included at your
link). The definition of this term explicitly excludes the contents of
the GCC runtime libraries.  So, you can convey the "combination" under
terms "consistent with the licensing of the independent modules".  After
that point, the license of the runtime lib itself doesn't come into
play, and you can ship it together with your app (because that is "the
combination").


Now, if you've modified the runtime lib, then at some point you had to
compile it, right?  Well, because its contents are EXCLUDED from the
definition of "Independent Module"s, the license exception doesn't apply
to the product of THAT compilation process. Therefore, distribution of
your new modified runtime lib requires distribution of ITS source.
However, if you then use that modified runtime lib to build another app,
then the same analysis above applies: no viralness extends to
Independent Modules.

But none of that applies to pthreads-win32. Its license is strict LGPL
-- which says "you have to provide source for this library, with all
your changes to it" (Whether it "virally" infects your app with
GPLishness, at all, or only if statically linked, etc, we'll leave to
the real lawyers. I've told you what my company's lawyers say.)

>> (B) Opinions vary, but some people claim that if you link
>> *statically* against an LGPL library, then the LGPL becomes just as
>> "viral" as the GPL -- and you have to distribute the source code of
>> your application.
>
> Is there a static version of pthreads-win32 or is this hypothetical?

It's about any LGPL library. The upstream pthreads-win32 project does
provide static libs; mingw's packages do not -- even our "libpthread.a"
is just an import lib for the DLL.

> If so, there are different versions of LGPL, and we need to know
> which you are referring to (3.0 mentions dynamic mechanisms, 2.1 does
> not, and pthreads-win32 2.8.0 seems to use the latter).

I'm not up on all the differences between the 2.x and 3.0 versions of
the (L)GPL.  I suspect the confusion about dyn/stat linking + LGPL is
*why* LGPL3.0 mentions dynamic linking, but I'll have to research it.

But, to repeat the preface: this whole discussion REALLY boils down to:
IANAL, YANAL, so nobody needs to listen to either one of us (but the
folks who wrote the GPL FAQ *are* lawyers, so we should probably listen
to them). Also, seek competent counsel and pay for your own analysis of
the licenses, if this is a business-critical need for you.

--
Chuck

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Loading...