public inbox for
 help / color / mirror / Atom feed
From: Ross Johnson <>
To: "" <>
Subject: Re: Static linking under win32
Date: Mon, 06 Dec 2004 07:52:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Gili wrote:

>	And here is an ugly question that has to be asked... I recently
>read this:
>	The implication seems to be that if my product links against a
>LGPL library (pthreads-win32 is such a library) then it must adhere to
>certain restrictions as set down by the LGPL. Two items I am
>specifically concerned with:
>1) The LGPL library source-code must be restributed in full with the
No! That's the GPL (and even then not strictly true IMO), not the LGPL.

If you statically link pthreads-win32 with your application, you will 
need to provide access to object files such that your users can relink 
the application with, for example, an updated pthread-win32. That is, 
you might provide yourapp.obj such that a user could build pthreadVC.obj 
from source and relink to create yourapp.exe. Both the GPL and the LGPL 
allow you to recover the cost of providing the extra material by the 
way. You don't have to provide this material on the distribution media, 
although many do because it's administratively easier, but you must tell 
your users that the material is available and provide some form of 
reasonable access to it.

Read the preamble to the LGPL to see what the LGPL is actually trying to 
achieve. The legalese is the technical expression of that, but people 
get wound up in their lay interpretations of the legalese. (And some 
people just like to wind other people up over it too.)

Please note that if you use the pthreads-win32 DLL, you don't have to 
provide anything apart from including the pthreads-win32 copyright along 
with your own copyright.

>2) I must grant users the right to reverse-engineer my product
No! Not necessarily IMO.

Without checking the license in detail, I would expect this to be true 
in either case only if you don't provide the material they need to 
rebuild/relink the application. That is, IMO this would be intended to 
provide legal sanction for desperate users if and when you have not 
upheld your side of the bargain. For example, suppose you modify your 
copy of pthreads-win32 somehow in such a way as to make it incompatible 
with the public version and don't provide the necessary information or 
materials to allow relinking.

>	Now, not to start a religious warfare here (since it is not my
>intent), but I'd like to clarify if this your intent as well? If I use
>it in my product, must I do these two things?
Some time ago there was a proposal to change the license to a more 
liberal Open Source license, but any change would require the agreement 
of everyone who has contributed significantly to the project, if not 
everyone who has contribributed. I guess if the current IBM-SCO case 
goes badly, then that proposal would be quickly resurrected.

Finally, since I'm not a lawer, you must obtain your own independent 
advice on this, but I believe that what I've
said above is consistent with the generally accepted and working 
interpretation of the LGPL.


>On Mon, 06 Dec 2004 17:22:38 +1100, Ross Johnson wrote:
>>Gili wrote:
>>>	I'm sure this is a commonly asked question: how do I build
>>>pthreads-win32 under VC++ (7.1 in my case)? I am surprised you don't
>>>ship a project file with the source-code or discuss this in the FAQ :)
>>Yes, it should be in the FAQ.
>>Pthreads-win32 relies on dynamic linking to provide a seemless interface 
>>to it's POSIX functionality - using dllMain to do some per process and 
>>per thread initialisation and cleanup. Static linking requires your 
>>application to call some non-portable routines (see README.NONPORTABLE: 
>>pthread_win32_process_attach_np etc). That's one reason why static 
>>linking is not really 'officially' encouraged.
>>However, there's a VS Workspace file provided that will build the DLL. 
>>It was contributed by a user and I use it for debugging sometimes. 
>>Perhaps you can modify that one and send me the result.
>>Nor do the makefiles that I use to build and test include targets for 
>>static linking.

       reply	other threads:[~2004-12-06  7:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2004-12-06  7:52 ` Ross Johnson [this message]
2004-12-06  9:57   ` Alexander Terekhov
2004-12-06 10:46   ` Keresztfalvi Laszlo
2004-12-06 17:35     ` Phil Frisbie, Jr.
2004-12-06 17:47       ` Gili
2004-12-06 18:07       ` Alexander Terekhov
     [not found]       ` <>
2004-12-06 20:08         ` Keresztfalvi Laszlo
     [not found] <>
2004-12-06 18:53 ` Alexander Terekhov
     [not found] <>
2004-12-06  6:22 ` Ross Johnson
2004-12-06  6:35   ` Gili
2004-12-06  3:37 Gili

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).