Re: [Mingw-w64-public] Relative path linking

[Mark Dootson]

Hi,

You can also do it with manifests. The example attached manifests allow 
an executable in directory c:\bin to load libstdc++-6.dll and 
libgcc_s_sjlj-1.dll from a subdirectory. Nothing is needed other than 
the manifests. The subdirectory is not on the PATH.


The directory and file structure is:

C:\bin\myexecutable.exe
C:\bin\mylocalassembly\mylocalassembly.manifest
C:\bin\mylocalassembly\libstdc++-6.dll
C:\bin\mylocalassembly\libgcc_s_sjlj-1.dll

The attached 'application.manifest' is compiled into myexecutable.exe.
The plain text file 'mylocalassembly.manifest' is also attached.

In brief - the manifest compiled into myexecutable.exe says it has a 
dependency on assembly 'mylocalassembly'. The windows loading mechanism 
will treat the subdirectory 'mylocalassembly' as containing the required 
assembly. You can add whatever you like to the 'file' list in 
mylocalassembly.manifest


It is an excellent way of solving the conflicting 'libgcc on path' 
problem. It would also allow myexecutable32.exe and myexecutable64.exe 
to be in the same directory and have the same PATH - just have different 
assembly dependencies.


Works for Windows XP onwards.

Note that the Windows loading mechanism is quite sensitive to the 
manifest format so make sure your format is the same as example. 
processorArchitecture for 32 bit is "x86", for 64 bit "amd64". Note the 
lower case. Different versions of Windows are fussier than others.


Hope it helps.



On 26/10/2012 16:34, Kai Tietz wrote:

2012/10/26 Алексей Павлов:

Hi!
Can I link program with shared library that not in PATH by relative path on
windows? I have structure like below:

  
  MyApplication.Application
  

  

  
  

  

  
  

  

  

  







--
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Herb Thompson]

On 2012-10-26 1:35 PM, Earnie Boyd wrote:
> On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
>  wrote:
>>
>> Also, can someone clarify that you only need to be able to provider the
>> source when asked for it vs providing it in some public place, which might
>> not even be reachable everywhere in the world?
>
> AIUI, at least for v2 of the license, you need to be able to provide
> the source for the exact version the user has in possession via the
> same media that the binary was delivered when asked for it.  It is
> easier if you just deliver the source and the same time you deliver
> the binary since you can tell the user he already has the source.
>

Not that this thread needs yet another opinion, but this is an 
interesting and important discussion.

So two minor comments:

(1) As I see it, the distinction between "distribute" and "provide" is 
important.  All of the major Linux distros I'm acquainted with (e.g. EL, 
Suse, Ubuntu, etc) *distribute* libstdc++.so via ISO images that do not 
include the source code, but *provide* the source code via some other 
means (that isn't always very visible to the end user).

(2) Depending on how one interprets "via the same media that the binary 
was delivered", I'm not sure that all of the major distros would achieve 
that. If for example I obtain a libstdc++.so via an Ubuntu ISO, I'm not 
sure I could get the source code in the same form.


Regards,
Herb Thompson


--
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

[Jon]

> So I would like to get your opinion.  You might have complete
> different opinion about planning mingw-w64's release-cycles, so don't
> hesitate to tell us what you think about this subject.


First, thanks for keeping the discussion open. It has been informative so far.

Second, as a consumer of mingw-w64 artifacts via Ruben and nixman's notable 
efforts, I share NightStrike's perspective and have the following 
amplifications:

1) Non-discretion based major version release cycles are likely to decrease 
usability if the mindset moves to only-release-at-specific-timeframes from 
release-when-feature-ready based upon real-world demand and committer 
evaluation. I much prefer that you guys stay motivated to push out features 
when ready than potentially waiting for artificial timeframes. The mingw-w64 
project is vastly different than Ubuntu.

2) mingw-w64 is ingredient technology useful for downstream integrators such as 
Ruben and nixman. Changing mingw-w64 to schedule based releases may negatively 
affect their releases. Better to push out the features when ready and count on 
their expertise/ability to manage which version should be part of their 
release. As an added benefit, mingw-w64 committers can push certain classes of 
support issues downstream where they belong"Our release X.Y.Z release 
addresses the issue. Talk to ? and ask them update their release." Keep 
Ruben from slacking ;)

Continue to focus on what you do well: release quality versions when they're 
ready, and enable downstream integrators to choose the version they feel is the 
best for their needs. Hard, schedule-based major version release cycles aren't 
a good fit for mingw-w64. Perhaps for other projects similar to Ubuntu, but not 
mingw-w64.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ray Donnelly]

> Also, can someone clarify that you only need to be able to provider the 
> source when asked for it vs providing it in some public place, which might 
> not even be reachable everywhere in the world?

I think it'd be best if you provided the correct sources with your
builds of GCC, so that the end user can simply take the archive you've
provided pass that archive on (and COPYING*) with their built
applications.

As for LLVM vs GCC, well that's a whole other matter, and giving the
users choice of both is best!

On Fri, Oct 26, 2012 at 5:35 PM, Earnie Boyd
 wrote:
> On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
>  wrote:
>>
>> Also, can someone clarify that you only need to be able to provider the
>> source when asked for it vs providing it in some public place, which might
>> not even be reachable everywhere in the world?
>
> AIUI, at least for v2 of the license, you need to be able to provide
> the source for the exact version the user has in possession via the
> same media that the binary was delivered when asked for it.  It is
> easier if you just deliver the source and the same time you deliver
> the binary since you can tell the user he already has the source.
>
> --
> Earnie
> -- https://sites.google.com/site/earnieboyd
>
> --
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
 wrote:
>
> Also, can someone clarify that you only need to be able to provider the
> source when asked for it vs providing it in some public place, which might
> not even be reachable everywhere in the world?

AIUI, at least for v2 of the license, you need to be able to provide
the source for the exact version the user has in possession via the
same media that the binary was delivered when asked for it.  It is
easier if you just deliver the source and the same time you deliver
the binary since you can tell the user he already has the source.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ruben Van Boxem]

Op 26 okt. 2012 18:10 schreef "Ray Donnelly"  het
volgende:
>
> Ok, if this is all true, then IMHO, ideally the necessary sources
> would be included with every build (even binary) of mingw gcc, with a
> big README explaining these legal requirements.

See the COPYING* files in the source distribution or the mingw??/licenses
directory in my builds. Granted, those are the raw license texts, but hey,
who am I to clarify legal texts... the one thing I thought I knew was wrong
:-)

Also, can someone clarify that you only need to be able to provider the
source when asked for it vs providing it in some public place, which might
not even be reachable everywhere in the world?

Complete side note: LLVM/Clang and associated libraries don't have these
problems, but need attention for Windows ;-) in order to provide a complete
replacement for GCC's infrastructure.

Ruben

>
> On Fri, Oct 26, 2012 at 5:05 PM, Earnie Boyd
>  wrote:
> > On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> >> On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
> >>> On Oct 26 16:10, Ray Donnelly wrote:
>  I've never seen any precedent of anyone ever doing this anywhere.
> 
>  Are you saying we are all in violation here? If so, 'we' includes a
>  huge amount of developers and applications (every Windows C++
>  application built with GCC!)
> >>>
> >>> No, that's not the case.  This is the kind of FUD which is spread
> >>> way too often, unfortunately.  There's an important difference here.
> >>>
> >>> Assuming you create a Linux application which is linked against glibc,
> >>> then you can provide binaries of your application, as well as sources
if
> >>> it's an open source project, at your sole discretion.  There's no
reason
> >>> to provide glibc together with your application since you can be
pretty
> >>> sure that glibc exists on any target computer.
> >>>
> >>> But what if you *do* provide glibc together with your application?  In
> >>> that case you provide a binary of a (L)GPLed product.  Now that you
> >>> provide this binary, you're also required to provide the sources for
> >>> that binary since your user has the right to get the sources as well.
> >>>
> >>> Keep in mind that the GPL is a user-centric license.  In a way, you as
> >>> developer are not the beneficiary of this license, but the user of the
> >>> product is, by making sure that the user retains the right to see the
> >>> sources of the product, whoever distributes that product.
> >>>
> >>> Does that make the situation clearer?
> >>>
> >>
> >> No, less clear, you've said that I've just spread some FUD, then
> >> appear to repeat exactly what I said.
> >>
> >> In your response, s/glibc/libstdc++.dll/ to see what I mean!
> >>
> >> I build a Qt application (Necessitas Qt Creator) for Windows and we
> >> distribute it with libstdc++-6.dll, so from what I'm gathering, we
> >> should also be providing the sources for this?
> >>
> >> Many thanks for increasing the U factor in FUD!
> >
> > I understood Corinna to mean "This is the kind of FUD" relative to the
> > "you don't need to distribute source, just point somewhere else" FUD
> > and the reason I butted in.  If you distribute libstc++-6.dll then yes
> > you need to distribute the source that created it.
> >
> > --
> > Earnie
> > -- https://sites.google.com/site/earnieboyd
> >
> >
--
> > The Windows 8 Center
> > In partnership with Sourceforge
> > Your idea - your app - 30 days. Get started!
> > http://windows8center.sourceforge.net/
> >
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Corinna Vinschen]

On Oct 26 12:05, Earnie Boyd wrote:
> On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> > On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
> >> On Oct 26 16:10, Ray Donnelly wrote:
> >>> I've never seen any precedent of anyone ever doing this anywhere.
> >>>
> >>> Are you saying we are all in violation here? If so, 'we' includes a
> >>> huge amount of developers and applications (every Windows C++
> >>> application built with GCC!)
> >>
> >> No, that's not the case.  This is the kind of FUD which is spread
> >> way too often, unfortunately.  There's an important difference here.
> >>
> >> Assuming you create a Linux application which is linked against glibc,
> >> then you can provide binaries of your application, as well as sources if
> >> it's an open source project, at your sole discretion.  There's no reason
> >> to provide glibc together with your application since you can be pretty
> >> sure that glibc exists on any target computer.
> >>
> >> But what if you *do* provide glibc together with your application?  In
> >> that case you provide a binary of a (L)GPLed product.  Now that you
> >> provide this binary, you're also required to provide the sources for
> >> that binary since your user has the right to get the sources as well.
> >>
> >> Keep in mind that the GPL is a user-centric license.  In a way, you as
> >> developer are not the beneficiary of this license, but the user of the
> >> product is, by making sure that the user retains the right to see the
> >> sources of the product, whoever distributes that product.
> >>
> >> Does that make the situation clearer?
> >>
> >
> > No, less clear, you've said that I've just spread some FUD, then
> > appear to repeat exactly what I said.

I didn't mean to imply you spread FUD, but that you're a victim to FUD.

> > In your response, s/glibc/libstdc++.dll/ to see what I mean!
> >
> > I build a Qt application (Necessitas Qt Creator) for Windows and we
> > distribute it with libstdc++-6.dll, so from what I'm gathering, we
> > should also be providing the sources for this?
> >
> > Many thanks for increasing the U factor in FUD!

I'm sorry, but it's not really my fault, is it?

> I understood Corinna to mean "This is the kind of FUD" relative to the
> "you don't need to distribute source, just point somewhere else" FUD
> and the reason I butted in.  If you distribute libstc++-6.dll then yes
> you need to distribute the source that created it.

Exactly.  Provide the binary -> provide the source.  That's pretty
simple from my POV.  I never understood why that's a problem.  Again,
you're not doing that for you or for the developers of libstc++,
you're doing it for the users.  Even if 99% of the users don't
understand the source and don't see the need to get it, they still
have the *right* to it.


Corinna

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ray Donnelly]

Ok, if this is all true, then IMHO, ideally the necessary sources
would be included with every build (even binary) of mingw gcc, with a
big README explaining these legal requirements.

On Fri, Oct 26, 2012 at 5:05 PM, Earnie Boyd
 wrote:
> On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
>> On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
>>> On Oct 26 16:10, Ray Donnelly wrote:
 I've never seen any precedent of anyone ever doing this anywhere.

 Are you saying we are all in violation here? If so, 'we' includes a
 huge amount of developers and applications (every Windows C++
 application built with GCC!)
>>>
>>> No, that's not the case.  This is the kind of FUD which is spread
>>> way too often, unfortunately.  There's an important difference here.
>>>
>>> Assuming you create a Linux application which is linked against glibc,
>>> then you can provide binaries of your application, as well as sources if
>>> it's an open source project, at your sole discretion.  There's no reason
>>> to provide glibc together with your application since you can be pretty
>>> sure that glibc exists on any target computer.
>>>
>>> But what if you *do* provide glibc together with your application?  In
>>> that case you provide a binary of a (L)GPLed product.  Now that you
>>> provide this binary, you're also required to provide the sources for
>>> that binary since your user has the right to get the sources as well.
>>>
>>> Keep in mind that the GPL is a user-centric license.  In a way, you as
>>> developer are not the beneficiary of this license, but the user of the
>>> product is, by making sure that the user retains the right to see the
>>> sources of the product, whoever distributes that product.
>>>
>>> Does that make the situation clearer?
>>>
>>
>> No, less clear, you've said that I've just spread some FUD, then
>> appear to repeat exactly what I said.
>>
>> In your response, s/glibc/libstdc++.dll/ to see what I mean!
>>
>> I build a Qt application (Necessitas Qt Creator) for Windows and we
>> distribute it with libstdc++-6.dll, so from what I'm gathering, we
>> should also be providing the sources for this?
>>
>> Many thanks for increasing the U factor in FUD!
>
> I understood Corinna to mean "This is the kind of FUD" relative to the
> "you don't need to distribute source, just point somewhere else" FUD
> and the reason I butted in.  If you distribute libstc++-6.dll then yes
> you need to distribute the source that created it.
>
> --
> Earnie
> -- https://sites.google.com/site/earnieboyd
>
> --
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
>> On Oct 26 16:10, Ray Donnelly wrote:
>>> I've never seen any precedent of anyone ever doing this anywhere.
>>>
>>> Are you saying we are all in violation here? If so, 'we' includes a
>>> huge amount of developers and applications (every Windows C++
>>> application built with GCC!)
>>
>> No, that's not the case.  This is the kind of FUD which is spread
>> way too often, unfortunately.  There's an important difference here.
>>
>> Assuming you create a Linux application which is linked against glibc,
>> then you can provide binaries of your application, as well as sources if
>> it's an open source project, at your sole discretion.  There's no reason
>> to provide glibc together with your application since you can be pretty
>> sure that glibc exists on any target computer.
>>
>> But what if you *do* provide glibc together with your application?  In
>> that case you provide a binary of a (L)GPLed product.  Now that you
>> provide this binary, you're also required to provide the sources for
>> that binary since your user has the right to get the sources as well.
>>
>> Keep in mind that the GPL is a user-centric license.  In a way, you as
>> developer are not the beneficiary of this license, but the user of the
>> product is, by making sure that the user retains the right to see the
>> sources of the product, whoever distributes that product.
>>
>> Does that make the situation clearer?
>>
>
> No, less clear, you've said that I've just spread some FUD, then
> appear to repeat exactly what I said.
>
> In your response, s/glibc/libstdc++.dll/ to see what I mean!
>
> I build a Qt application (Necessitas Qt Creator) for Windows and we
> distribute it with libstdc++-6.dll, so from what I'm gathering, we
> should also be providing the sources for this?
>
> Many thanks for increasing the U factor in FUD!

I understood Corinna to mean "This is the kind of FUD" relative to the
"you don't need to distribute source, just point somewhere else" FUD
and the reason I butted in.  If you distribute libstc++-6.dll then yes
you need to distribute the source that created it.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Fri, Oct 26, 2012 at 11:39 AM, Ruben Van Boxem
 wrote:
>
> I also don't think a static runtime link changes any of this, TDM. >From the
> same FAQ as before:
> "neither the GPL nor the GCC Runtime Library Exception distinguish between
> static linking, dynamic linking, and other methods for combining code in
> their conditions"
>
> So I doubt your forced static runtime linking affects any of this.

The static linking reduces the need to distribute the shared library.
It is the shared library whose source needs distributed when you
distribute the shared library.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ray Donnelly]

On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen  wrote:
> On Oct 26 16:10, Ray Donnelly wrote:
>> I've never seen any precedent of anyone ever doing this anywhere.
>>
>> Are you saying we are all in violation here? If so, 'we' includes a
>> huge amount of developers and applications (every Windows C++
>> application built with GCC!)
>
> No, that's not the case.  This is the kind of FUD which is spread
> way too often, unfortunately.  There's an important difference here.
>
> Assuming you create a Linux application which is linked against glibc,
> then you can provide binaries of your application, as well as sources if
> it's an open source project, at your sole discretion.  There's no reason
> to provide glibc together with your application since you can be pretty
> sure that glibc exists on any target computer.
>
> But what if you *do* provide glibc together with your application?  In
> that case you provide a binary of a (L)GPLed product.  Now that you
> provide this binary, you're also required to provide the sources for
> that binary since your user has the right to get the sources as well.
>
> Keep in mind that the GPL is a user-centric license.  In a way, you as
> developer are not the beneficiary of this license, but the user of the
> product is, by making sure that the user retains the right to see the
> sources of the product, whoever distributes that product.
>
> Does that make the situation clearer?
>

No, less clear, you've said that I've just spread some FUD, then
appear to repeat exactly what I said.

In your response, s/glibc/libstdc++.dll/ to see what I mean!

I build a Qt application (Necessitas Qt Creator) for Windows and we
distribute it with libstdc++-6.dll, so from what I'm gathering, we
should also be providing the sources for this?

Many thanks for increasing the U factor in FUD!

>
> Corinna
>
>>
>> On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen  
>> wrote:
>> > On Oct 26 15:04, Ruben Van Boxem wrote:
>> >> And that Section 6 clearly states you can point to e.g. the GCC website 
>> >> for
>> >> the source code:
>> >> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
>> >
>> > No, you're misinterpreting that.  Read again.  *You* can provide the
>> > sources of the GPLed stuff you're providing in binary form on another
>> > site.  That does not imply that you can burden *somebody else*, aka the
>> > GCC website, with the resposibility to provide the source code for you.
>> >
>> >
>> > Corinna
>> >
>> > --
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_sfd2d_oct
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>> --
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> --
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ruben Van Boxem]

2012/10/26 Kai Tietz 

> Yes, you have to take care to provide a link to source-code or the
> source itself of the gcc libraries with runtime-exception you are
> using.  It is not enough to point to somebody else, which might
> provide the sources.
>   Btw this is the cause why mingw-w64 always does binary and
> source-package releases of toolchain.
>   I admit that not all people are aware of that, but it is the
> interpretation of the GPL with runtime-exception, which shared among
> most involved people.  I spoke about this with RMS at Prague and he
> agreed to this understanding of the GPL runtime-exception license.
> I see here much violations even on some software provided as
> binary-only packages on Linux. Windows developers aren't they only one
> misinterpreting the runtime-license of gcc here.
>

OK. But GCC pulling down its sources is highly unlikely, and if that
happens, I'm quite sure someone will have remembered to back it up
somewhere. FWIW, all my toolchains' sources are available on SF.net.

I also don't think a static runtime link changes any of this, TDM. From the
same FAQ as before:
"neither the GPL nor the GCC Runtime Library Exception distinguish between
static linking, dynamic linking, and other methods for combining code in
their conditions"

So I doubt your forced static runtime linking affects any of this.

Cheers,

Ruben

>
> Kai
>
> PS: IANAL but able to ask
>
>
> --
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Corinna Vinschen]

On Oct 26 16:10, Ray Donnelly wrote:
> I've never seen any precedent of anyone ever doing this anywhere.
> 
> Are you saying we are all in violation here? If so, 'we' includes a
> huge amount of developers and applications (every Windows C++
> application built with GCC!)

No, that's not the case.  This is the kind of FUD which is spread
way too often, unfortunately.  There's an important difference here.

Assuming you create a Linux application which is linked against glibc,
then you can provide binaries of your application, as well as sources if
it's an open source project, at your sole discretion.  There's no reason
to provide glibc together with your application since you can be pretty
sure that glibc exists on any target computer.

But what if you *do* provide glibc together with your application?  In
that case you provide a binary of a (L)GPLed product.  Now that you
provide this binary, you're also required to provide the sources for
that binary since your user has the right to get the sources as well.

Keep in mind that the GPL is a user-centric license.  In a way, you as
developer are not the beneficiary of this license, but the user of the
product is, by making sure that the user retains the right to see the
sources of the product, whoever distributes that product.

Does that make the situation clearer?


Corinna

> 
> On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen  wrote:
> > On Oct 26 15:04, Ruben Van Boxem wrote:
> >> And that Section 6 clearly states you can point to e.g. the GCC website for
> >> the source code:
> >> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
> >
> > No, you're misinterpreting that.  Read again.  *You* can provide the
> > sources of the GPLed stuff you're providing in binary form on another
> > site.  That does not imply that you can burden *somebody else*, aka the
> > GCC website, with the resposibility to provide the source code for you.
> >
> >
> > Corinna
> >
> > --
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Relative path linking

[Kai Tietz]

2012/10/26 Алексей Павлов :
> Hi!
> Can I link program with shared library that not in PATH by relative path on
> windows? I have structure like below:
>
> ORIGIN
>   |- bin
>   |   \-program.exe
>   |- opt
>   |   |-lib
>   |   |   \-mylib.dll

Yes, this is possible.  But DLL loading mechanism works different to
that one you know from ELF systems.

> I try to add arguments to LDFLAGS
>   Wl,-rpath,'../opt/lib' -L/path/to/lib -lmylib
> But without success(

Yes, that won't work.

Common solution for this is to add sub-directory to PATH before
execution of application.  This can be done by a stub-application,
which just modifies PATH and then executes *real* app.
Other way to solve this is by using delayed and/or manual DLL loading
code.  By delayed version you can modify PATH variable local to your
own app before calling external DLL code, or you are using LoadLibrary
directly, where you can specify any path for DLL to be loaded.

Hopes this helps,
Kai

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Kai Tietz]

Yes, you have to take care to provide a link to source-code or the
source itself of the gcc libraries with runtime-exception you are
using.  It is not enough to point to somebody else, which might
provide the sources.
  Btw this is the cause why mingw-w64 always does binary and
source-package releases of toolchain.
  I admit that not all people are aware of that, but it is the
interpretation of the GPL with runtime-exception, which shared among
most involved people.  I spoke about this with RMS at Prague and he
agreed to this understanding of the GPL runtime-exception license.
I see here much violations even on some software provided as
binary-only packages on Linux. Windows developers aren't they only one
misinterpreting the runtime-license of gcc here.

Kai

PS: IANAL but able to ask

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Relative path linking

[Алексей Павлов]

Hi!
Can I link program with shared library that not in PATH by relative path on
windows? I have structure like below:

*ORIGIN
  |- bin
  |   \-program.exe
  |- opt
  |   |-lib
  |   |   \-mylib.dll*

I try to add arguments to LDFLAGS
  *Wl,-rpath,'../opt/lib' -L/path/to/lib -lmylib*
But without success(
--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[John E. / TDM]

On 10/26/2012 6:52 AM, Earnie Boyd wrote:
> IANAL either but I am not spreading FUD.  The exception covers the use
> and not the distribution.  If you don't believe me ask Richard
> Stallman.
>
> http://www.gnu.org/licenses/gcc-exception-3.1-faq.html";>
> *snip*
> Note that if you distribute libstdc++ as an independent library, you
> will need to follow the terms of the GPL when doing so. For example,
> if you distribute the library itself in object code form, you will
> need to provide source code to your recipients using one of the
> methods listed in section 6 of GPLv3. But as long as you are eligible
> to take advantage of the GCC Runtime Library Exception's permissions
> for your own program, the GPL's terms do not extend to it.
> 

-- and this is why I go through such pains to keep TDM-GCC's static 
runtime linkage alive. Distributing the GCC runtime libraries' sources 
is a burdensome requirement, and one I suspect more than a few 
developers are in violation of.

-John E. / TDM

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ray Donnelly]

I've never seen any precedent of anyone ever doing this anywhere.

Are you saying we are all in violation here? If so, 'we' includes a
huge amount of developers and applications (every Windows C++
application built with GCC!)

On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen  wrote:
> On Oct 26 15:04, Ruben Van Boxem wrote:
>> And that Section 6 clearly states you can point to e.g. the GCC website for
>> the source code:
>> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
>
> No, you're misinterpreting that.  Read again.  *You* can provide the
> sources of the GPLed stuff you're providing in binary form on another
> site.  That does not imply that you can burden *somebody else*, aka the
> GCC website, with the resposibility to provide the source code for you.
>
>
> Corinna
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Corinna Vinschen]

On Oct 26 15:04, Ruben Van Boxem wrote:
> And that Section 6 clearly states you can point to e.g. the GCC website for
> the source code:
> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

No, you're misinterpreting that.  Read again.  *You* can provide the
sources of the GPLed stuff you're providing in binary form on another
site.  That does not imply that you can burden *somebody else*, aka the
GCC website, with the resposibility to provide the source code for you.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Fri, Oct 26, 2012 at 9:04 AM, Ruben Van Boxem
 wrote:
>
> And that Section 6 clearly states you can point to e.g. the GCC website for
> the source code:
> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
>
> So absolutely no end-developer hassle in providing toolchain source code is
> required.

Well there is some hassle

and you must take care to make sure that the source remains
available for as long as you distribute the object code.

The only way to do that for a guarantee is to have the sources handy
to distribute in the event the sited source removes their files or
goes away for any length of time.  The question is also stated in such
a manner that *you* are the one controlling both sites; i.e. the
answer to the question doesn't eliminate your responsibility to
provide the source.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

[JonY]

On 10/25/2012 17:17, JonY wrote:
> On 10/25/2012 15:04, Ruben Van Boxem wrote:
>> Currently, trunk has several new features, some of which have matured quite
>> a while ago (I'm looking at you, large file support for C streams). It also
>> has some more WIP stuff.
>>
> 
> If any branching is going to happen, please hold on, I'm still doing
> some final testing on the vswprintf fix for libstdc++ to_string.
> 
> Well, it shouldn't break anything since it wasn't working before anyway.

Patch to trunk CRT, I can't commit until it's tested enough.



Index: crt/stdio.h
===
--- crt/stdio.h (revision 5433)
+++ crt/stdio.h (working copy)
@@ -742,12 +742,22 @@
   return __mingw_vwprintf( __format, __local_argv );
 }

+/* For libstdc++ */
+#if defined(__cplusplus) && (__cplusplus >= 201103L) && defined(__GNUC__)
 __mingw_ovr
+/* __attribute__((__format__ (gnu_wprintf, 3, 0))) */ __MINGW_ATTRIB_NONNULL(3)
+int vswprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, 
__builtin_va_list __local_argv)
+{
+  return __mingw_vsnwprintf( __stream, __n, __format, __local_argv );
+}
+#else
+__mingw_ovr
 /* __attribute__((__format__ (gnu_printf, 2, 0))) */ __MINGW_ATTRIB_NONNULL(2)
 int vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list 
__local_argv)
 {
   return __mingw_vswprintf( __stream, __format, __local_argv );
 }
+#endif /* defined(__cplusplus) && (__cplusplus >= 201103L) && 
defined(__GNUC__) */

 #ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
 __mingw_ovr
Index: crt/wchar.h
===
--- crt/wchar.h (revision 5433)
+++ crt/wchar.h (working copy)
@@ -568,12 +568,22 @@
   return __mingw_vwprintf( __format, __local_argv );
 }

+/* For libstdc++ */
+#if defined(__cplusplus) && (__cplusplus >= 201103L) && defined(__GNUC__)
 __mingw_ovr
-/* __attribute__((__format__ (gnu_wprintf, 2, 0))) */ __MINGW_ATTRIB_NONNULL(2)
+/* __attribute__((__format__ (gnu_wprintf, 3, 0))) */ __MINGW_ATTRIB_NONNULL(3)
+int vswprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, 
__builtin_va_list __local_argv)
+{
+  return __mingw_vsnwprintf( __stream, __n, __format, __local_argv );
+}
+#else
+__mingw_ovr
+/* __attribute__((__format__ (gnu_printf, 2, 0))) */ __MINGW_ATTRIB_NONNULL(2)
 int vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list 
__local_argv)
 {
   return __mingw_vswprintf( __stream, __format, __local_argv );
 }
+#endif /* defined(__cplusplus) && (__cplusplus >= 201103L) && 
defined(__GNUC__) */

 /*#ifndef __NO_ISOCEXT */  /* externs in libmingwex.a */
 __mingw_ovr





signature.asc
Description: OpenPGP digital signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ruben Van Boxem]

2012/10/26 Earnie Boyd 

> On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem
>  wrote:
> > 2012/10/26 Earnie Boyd 
> >>
> >> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> >> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> >> > unless you stick strictly to C. Like Kai says, C++ support comes from
> >> > GCC libstdc++, fortran support from libgfortran etc. You should have
> no
> >> > legal problems distributing these DLLs with your programs in anyway.
> >>
> >> As long as the source of those DLL libraries is also distributed.
> >> Distributing binaries of GPL code (LGPL is GPL with an exception for
> >> binary use)  requires you to also distribute the source for those
> >> binaries; there is never an exception for that.
> >
> >
> > IANAL, but I can read.
> >
> > Stop spreading FUD. The GCC runtime libraries fall under a special
> exception
> > which is very liberal, as JonY intended to make unambiguously clear.
> Read up
> > on the subject here. The FAQ clearly states you can create proprietary
> > programs with these libraries as long as you don't use a non-GPL
> compatible
> > GCC plugin to do code generation. It even explicitly states that you can
> > combine code generated by the Intel compiler with GCC-generated code, and
> > still be able to use the exception to just redistribute the runtime
> > libraries alongside your binaries. This has nothing to do with the
> license
> > of the code actually being compiled and linked.
>
> IANAL either but I am not spreading FUD.  The exception covers the use
> and not the distribution.  If you don't believe me ask Richard
> Stallman.
>
> http://www.gnu.org/licenses/gcc-exception-3.1-faq.html";>
> I use a proprietary compiler toolchain without any parts of GCC to
> compile my program, and link it with libstdc++. My program itself does
> not include any runtime library code the same way that GCC-compiled
> programs include libgcc. Can I still take advantage of the exception?
>
> Yes. While combining libgcc with GCC-compiled object code is probably
> the most common way the exception is used, neither the GPL nor the GCC
> Runtime Library Exception distinguish between static linking, dynamic
> linking, and other methods for combining code in their conditions. The
> same permissions are available to you, under the same terms, no matter
> which method you use.
>
> Note that if you distribute libstdc++ as an independent library, you
> will need to follow the terms of the GPL when doing so. For example,
> if you distribute the library itself in object code form, you will
> need to provide source code to your recipients using one of the
> methods listed in section 6 of GPLv3. But as long as you are eligible
> to take advantage of the GCC Runtime Library Exception's permissions
> for your own program, the GPL's terms do not extend to it.
> 
>

And that Section 6 clearly states you can point to e.g. the GCC website for
the source code:
http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

So absolutely no end-developer hassle in providing toolchain source code is
required.

Ruben


>
> --
> Earnie
> -- https://sites.google.com/site/earnieboyd
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem
 wrote:
> 2012/10/26 Earnie Boyd 
>>
>> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
>> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
>> > unless you stick strictly to C. Like Kai says, C++ support comes from
>> > GCC libstdc++, fortran support from libgfortran etc. You should have no
>> > legal problems distributing these DLLs with your programs in anyway.
>>
>> As long as the source of those DLL libraries is also distributed.
>> Distributing binaries of GPL code (LGPL is GPL with an exception for
>> binary use)  requires you to also distribute the source for those
>> binaries; there is never an exception for that.
>
>
> IANAL, but I can read.
>
> Stop spreading FUD. The GCC runtime libraries fall under a special exception
> which is very liberal, as JonY intended to make unambiguously clear. Read up
> on the subject here. The FAQ clearly states you can create proprietary
> programs with these libraries as long as you don't use a non-GPL compatible
> GCC plugin to do code generation. It even explicitly states that you can
> combine code generated by the Intel compiler with GCC-generated code, and
> still be able to use the exception to just redistribute the runtime
> libraries alongside your binaries. This has nothing to do with the license
> of the code actually being compiled and linked.

IANAL either but I am not spreading FUD.  The exception covers the use
and not the distribution.  If you don't believe me ask Richard
Stallman.

http://www.gnu.org/licenses/gcc-exception-3.1-faq.html";>
I use a proprietary compiler toolchain without any parts of GCC to
compile my program, and link it with libstdc++. My program itself does
not include any runtime library code the same way that GCC-compiled
programs include libgcc. Can I still take advantage of the exception?

Yes. While combining libgcc with GCC-compiled object code is probably
the most common way the exception is used, neither the GPL nor the GCC
Runtime Library Exception distinguish between static linking, dynamic
linking, and other methods for combining code in their conditions. The
same permissions are available to you, under the same terms, no matter
which method you use.

Note that if you distribute libstdc++ as an independent library, you
will need to follow the terms of the GPL when doing so. For example,
if you distribute the library itself in object code form, you will
need to provide source code to your recipients using one of the
methods listed in section 6 of GPLv3. But as long as you are eligible
to take advantage of the GCC Runtime Library Exception's permissions
for your own program, the GPL's terms do not extend to it.


-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Ruben Van Boxem]

2012/10/26 Earnie Boyd 

> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> > unless you stick strictly to C. Like Kai says, C++ support comes from
> > GCC libstdc++, fortran support from libgfortran etc. You should have no
> > legal problems distributing these DLLs with your programs in anyway.
>
> As long as the source of those DLL libraries is also distributed.
> Distributing binaries of GPL code (LGPL is GPL with an exception for
> binary use)  requires you to also distribute the source for those
> binaries; there is never an exception for that.
>

IANAL, but I can read.

Stop spreading FUD. The GCC runtime libraries fall under a special
exception which is very liberal, as JonY intended to make unambiguously
clear. Read up on the subject
here.
The FAQ clearly states you can create proprietary programs with these
libraries as long as you don't use a non-GPL compatible GCC plugin to do
code generation. It even explicitly states that you can combine code
generated by the Intel compiler with GCC-generated code, and still be able
to use the exception to just redistribute the runtime libraries alongside
your binaries. This has nothing to do with the license of the code actually
being compiled and linked.

Ruben


> --
> Earnie
> -- https://sites.google.com/site/earnieboyd
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[Earnie Boyd]

On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> unless you stick strictly to C. Like Kai says, C++ support comes from
> GCC libstdc++, fortran support from libgfortran etc. You should have no
> legal problems distributing these DLLs with your programs in anyway.

As long as the source of those DLL libraries is also distributed.
Distributing binaries of GPL code (LGPL is GPL with an exception for
binary use)  requires you to also distribute the source for those
binaries; there is never an exception for that.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Missing GUIDs for the Microsoft Speech API

[ナナシヤコブ]

The CLSIDs and IIDs for the classes and interfaces in the SAPI are
missing. In the Windows SDK they are contained as data in sapi.lib,
but I can't see them in libsapi.a.

I have attached a list of the CLSIDs and IIDs that are part of the
SAPI, with their corresponding GUID values (extracted from sapi.lib).
IID_ISpNotifySource = 5EFF4AEF-8487-11D2-1C96-8E4FC000
IID_ISpNotifySink = 259684DC-37C3-11D2-396-8E4FC000
IID_ISpNotifyTranslator = ACA16614-5D3D-11D2-E96-8E4FC000
IID_ISpDataKey = 14056581-E16C-11D2-90BB-8E4FC000
IID_ISpRegDataKey = 92A66E2B-C830-4149-DF83-1EBAC26F
IID_ISpObjectTokenCategory = 2D3D3845-39AF-4850-F9BB-8097B440
IID_ISpObjectToken = 14056589-E16C-11D2-90BB-8E4FC000
IID_ISpObjectTokenInit = B8AAB0CF-346F-49D8-9994-163FB0C8
IID_IEnumSpObjectTokens = 6B64F9E-7FDA-11D2-F2B4-794FC000
IID_ISpObjectWithToken = 5B559F40-E952-11D2-91BB-8E4FC000
IID_ISpResourceManager = 93384E18-5014-43D5-BBAD-59058EA7
IID_ISpEventSource = BE7A9CCE-5F9E-11D2-F96-8E4FC000
IID_ISpEventSource2 = 2373A435-6A4B-429E-ACA6-611A23D4
IID_ISpEventSink = BE7A9CC9-5F9E-11D2-F96-8E4FC000
IID_ISpStreamFormat = BED530BE-2606-4F4D-C0A1-A5CDC554
IID_ISpStream = 12E3CCA9-7518-44C5-E7A5-CB795ABA
IID_ISpStreamFormatConverter = 678A932C-EA71-4446-419B-28A6FD78
IID_ISpAudio = C05C768F-FAE8-4EC2-78E-C1218333
IID_ISpMMSysAudio = 15806F6E-1D70-4B48-E698-75001A3B
IID_ISpTranscript = 10F63BCE-201A-11D3-70AC-8E4FC000
IID_ISpLexicon = DA41A7C2-5383-4DB2-6B91-E319176C
IID_ISpContainerLexicon = 8565572F-C094-41CC-6EB5-3F9CBD10
IID_ISpShortcut = 3DF681E2-EA56-11D9-DE8B-1EAD6BF6
IID_ISpPhoneConverter = 8445C581-CAC-4A38-FEAB-82E22C9B
IID_ISpPhoneticAlphabetConverter = 133ADCD4-19B4-4020-DC9F-25782E84
IID_ISpPhoneticAlphabetSelection = B2745EFD-42CE-48CA-F181-53026EA9
IID_ISpVoice = 6C44DF74-72B9-4992-ECA1-46E99EF
IID_ISpPhrase = 1A5C0354-B621-4B5A-9187-37ED06D3
IID_ISpPhraseAlt = 8FCEBC98-4E49-4067-6C9C-90E6AD8
IID_ISpPhrase2 = F264DA52-E457-4696-56B8-17B737A7
IID_ISpRecoResult = 20B053BE-E235-43CD-2A9A-8BA4178D
IID_ISpRecoResult2 = 27CAC6C4-88F2-41F2-1788-9FE5950C
IID_ISpXMLRecoResult = AE39362B-45A8-4074-9E9B-A29AF4CC
IID_ISpGrammarBuilder = 8137828F-591A-4A42-58BE-BA7EEA49
IID_ISpRecoGrammar = 2177DB29-7F45-47D0-5485-C8917E06
IID_ISpGrammarBuilder2 = 8AB10026-20CC-4B20-228C-A79B9CA4
IID_ISpRecoGrammar2 = 4B37BC9E-9ED6-44A3-D393-B722F018
IID_ISpeechResourceLoader = B9AC5783-FCD0-4B21-19B1-8FDAF8B4
IID_ISpRecoContext = F740A62F-7C15-489E-3482-D9330A94
IID_ISpRecoContext2 = BEAD311C-52FF-437F-6494-4C05216B
IID_ISpProperties = 5B4FB971-B115-4DE1-97AD-BFE382E4
IID_ISpRecognizer = C2B5F241-DAA0-4507-169E-2BAA1E5A
IID_ISpSerializeState = 21B501A0-EC7-46C9-C392-4C78BCA2
IID_ISpRecognizer2 = 8FC6D974-C81E-4098-C593-1EF64701
IID_ISpRecoCategory = DA0CD0F9-14A2-4F09-2A8C-9748CC85
IID_ISpRecognizer3 = DF1B943C-5838-4AA2-687-335BCDD7
IID_ISpEnginePronunciation = C360CE4B-76D1-4214-68AD-507D6552
IID_ISpeechDataKey = CE17C09B-4EFA-44D5-C9A4-5A58D959
IID_ISpeechObjectToken = C74A3ADC-B727-4500-4AA8-1C7226B5
IID_ISpeechObjectTokens = 9285B776-2E7B-4BC0-3EB5-FAB60E58
IID_ISpeechObjectTokenCategory = CA7EAC50-2D01-4145-D486-FD7E75A
IID_ISpeechAudioBufferInfo = 11B103D8-1142-4EDF-93A0-1539FB82
IID_ISpeechAudioStatus = C62D9C91-7458-47F6-2D86-B06FF81E
IID_ISpeechAudioFormat = E6E9C590-3E18-40E3-9982-BD981F06
IID_ISpeechWaveFormatEx = 7A1EF0D5-1581-4741-E488-F1499A20
IID_ISpeechBaseStream = 6450336F-7D49-4CED-9780-E3DED649
IID_ISpeechFileStream = AF67F125-AB39-4E93-A2B4-E1662ECC
IID_ISpeechMemoryStream = EEB14B68-808B-4ABE-EAA5-58A71DB5
IID_ISpeechCustomStream = 1A9E9F4F-104F-4DB8-15A1-CFDD7EF
IID_ISpeechAudio = CFF8E175-19E-11D3-8EA0-8E4FC000
IID_ISpeechMMSysAudio = 3C76AF6D-1FD7-4831-D181-A1D5713B
IID_ISpeechVoice = 269316D8-57BD-11D2-EE9E-794FC000
IID_ISpeechVoiceStatus = 8BE47B07-57F6-11D2-EE9E-794FC000
IID_ISpeechRecognizer = 2D5F1C0C-BD75-4B08-7894-A2FE113B
IID_ISpeechRecognizerStatus = BFF9E781-53EC-484E-8ABB-51551B0E
IID_ISpeechRecoContext = 580AA49D-7E1E-4809-E2B8-6180DA57
IID_ISpeechRecoGrammar = B6D6F79F-2158-4E50-BCB5-85CD9C9A
IID_ISpeechGrammarRule = AFE719CF-5DD1-44F2-9C99-1C9F397A
IID_ISpeechGrammarRules = 6FFA3B44-FC2D-40D1-FC8A-7F1C9132
IID_ISpeechGrammarRuleState = D4286F2C-EE67-45AE-28B9-3695D628
IID_ISpeechGrammarRuleStateTransition = CAFD1DB1-41D1-4A06-6398-A11DE8E2
IID_ISpeechGrammarRuleStateTransitions = EABCE657-75BC-44A2-7FAA-747664C5
IID_ISpeechTextSelectionInformation = 3B9C7E7A-6EEE-4DED-9290-79726511
IID_ISpeechRecoResult = ED2879CF-CED9-4EE6-34A5-D59101DE
IID_ISpeechRecoResult2 = 8E0A246D-D3C8-45DE-5786-450C2904
IID_ISpeechRecoResultTimes = 62B3B8FB-F6E7-41BE-CBBD-291C6B05
IID_ISpeechPhraseAlternate = 27864A2A-2B9F-4CB8-D392-FD22270D
IID_ISpeechPhraseAlternates = B238B6D5-F276-4C3D-C1A6-1C807429
IID_ISpeechPhraseInfo = 961559CF-4E67-4662-F08B-CD1F3FD9
IID_ISpeechPhraseElement = E6176F96-E373-4801-23B2-68C0623B
IID_ISpeechPhraseElements = 626B328-3478-467D-B3A0-933B85D0
IID_ISpeechPhraseReplacement = 2890A410-53A7-4FB5-EC94-8E99D406
IID_