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

[Simson Garfinkel]

I've been on this mailing list for some time now and use mingw (both the 32-bit 
and 64-bit versions) for several production systems. What I would like to see 
is not a commitment to a release schedule but a document that clearly states 
the commitment to specific principles. For example:

* Can compile the same source code as MSC VC++  (is this true?)

* No Microsoft copyrighted headers in the build tree (so reimplementation)

* Uses Microsoft DLLs, rather than GNU DLLs, for key functions (is this true 
anymore?)

* Compiles both Windows Threads and POSIX threads (true?)

* Equally produces static-linked and dynamic-linked binaries (this is VITAL for 
incident response.  The problem is that many of the packets in the repositories 
include dynamic versions but not static versions)

* Compiled code supports both gdb and Microsoft debugger tools (true?)

Anyway, you get the idea. If this list is available somewhere, I haven't seen 
it.



--
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

[Kai Tietz]

Helle Simson,

this list seems to me more like good content to our FAQ-section in
Wiki.  Some of those points might be defining general goals we wanna
to define, or decline for mingw-w64 in general.
Most of those points are looking like something desirable, but on a
technical POV it shows that some of those points aren't implementable
due missing definitions in specification, simple vendor differences,
and misunderstandings in general goals.  I will try to give brief
answers to your questions, and maybe somebody thinks it is worth to
add those answers to FAQ in our Wiki.

2012/10/25 Simson Garfinkel :
> I've been on this mailing list for some time now and use mingw (both the 
> 32-bit and 64-bit versions) for several production systems. What I would like 
> to see is not a commitment to a release schedule but a document that clearly 
> states the commitment to specific principles. For example:
>
> * Can compile the same source code as MSC VC++  (is this true?)

As long as source doesn't use vendor-specific extension, this is
possible.  We invested some efforts to add new features to gcc/g++ to
implement some compliant-features (eg x64 SEH exception in 4.8,
push_macro/pop_macro pragma, __int128, etc) which are vendor specific
VC extensions.  Also there were recently spend some efforts for g++ to
make call-ABI in class-member functions more compatible to that what
MS defines by its 32-bit ABI. Additionally we provide tools - like
gendef, genidl, widl, genpe, etc - which are trying to fill some gaps
in standard-toolchain. Nevertheless we won't be able to make both
compilers feature-identical and this can't be a serious goal as
official documentation and papers about those features aren't
available for us.

> * No Microsoft copyrighted headers in the build tree (so reimplementation)

Sure, this is a primary goal for us.  This doesn't mean that user
can't use for her/him-self additional SDKs provided by MS within our
toolchain.  As far as I learned are some user using for example the
DIA SDK successful.

> * Uses Microsoft DLLs, rather than GNU DLLs, for key functions (is this true 
> anymore?)

For platform-functions we have to use OS provided DLLs, which are of
course provided by MS.  For C-runtime we are using by default the
msvcrt.dll - this is a big subject and might need additional comments
as there are huge version-differences present - version. But of course
it is possible to build applications using different MS runtimes, like
msvcr100.dll, msvcr80.dll, etc. We don't use those DLLs by default, as
they aren't part of the standard-OS DLL set.
There are additional DLLs - and were ever for gcc/g++ based toolchains
- which are provided by the toolchain.  Typical libraries provided by
gcc are libgcc, libgfortran, libstdc++, libquadmath, libssp.
Those DLLs can be used, but you have then of course to redistribute
them to end-user for running your build app.  A way to avoid this is
to use static version of those libraries.  This avoids dependencies to
none-system DLLs in general - see -static options.
If you plan to use a different runtime DLL, you might be in need to
rebuild those gcc-target libraries, as they are build by most
pre-compiled toolchains only using msvcrt.dll (Side note that static
versions of gcc's libraries don't need to be rebuild here).

> * Compiles both Windows Threads and POSIX threads (true?)

Yes, that true if you are using a pthread library. There is
pthreads-win32 venture, or you can use winpthread - a mingw-w64 owned
sub-project - for this.  By using winpthread you are able to build
gcc's target-libraries in POSIX-way.

> * Equally produces static-linked and dynamic-linked binaries (this is VITAL 
> for incident response.  The problem is that many of the packets in the 
> repositories include dynamic versions but not static versions)

Sure, dynamic and static libraries are provided.  The issue about
static-version is in some cases the used license for them.  For gcc's
runtime-libraries there aren't any issues, as there is a
runtime-exception present, but for other libraries there might be
problems inflicted by license.  Eg (L)GPL's viral effect on license.

> * Compiled code supports both gdb and Microsoft debugger tools (true?)

Well, that is technical not really possible, as gdb doesn't supports
pdb-format (not offical documented as most of MS' debugging stuff),
and windbg doesn't supports dwarf-2 debugging information.  You should
be able to debug with both debuggers any application, but you won't be
able to see further debugging-info.

Regards,
Kai

--
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

[JonY]

On 10/26/2012 02:19, Kai Tietz wrote:
> Helle Simson,
> 
> this list seems to me more like good content to our FAQ-section in
> Wiki.  Some of those points might be defining general goals we wanna
> to define, or decline for mingw-w64 in general.
> Most of those points are looking like something desirable, but on a
> technical POV it shows that some of those points aren't implementable
> due missing definitions in specification, simple vendor differences,
> and misunderstandings in general goals.  I will try to give brief
> answers to your questions, and maybe somebody thinks it is worth to
> add those answers to FAQ in our Wiki.
> 
> 2012/10/25 Simson Garfinkel
>> I've been on this mailing list for some time now and use mingw (both the 
>> 32-bit and 64-bit versions) for several production systems. What I would 
>> like to see is not a commitment to a release schedule but a document that 
>> clearly states the commitment to specific principles. For example:
>>
>> * Can compile the same source code as MSC VC++  (is this true?)
> 
> As long as source doesn't use vendor-specific extension, this is
> possible.  We invested some efforts to add new features to gcc/g++ to
> implement some compliant-features (eg x64 SEH exception in 4.8,
> push_macro/pop_macro pragma, __int128, etc) which are vendor specific
> VC extensions.  Also there were recently spend some efforts for g++ to
> make call-ABI in class-member functions more compatible to that what
> MS defines by its 32-bit ABI. Additionally we provide tools - like
> gendef, genidl, widl, genpe, etc - which are trying to fill some gaps
> in standard-toolchain. Nevertheless we won't be able to make both
> compilers feature-identical and this can't be a serious goal as
> official documentation and papers about those features aren't
> available for us.
> 

Yes, this is a valid goal for us.

>> * No Microsoft copyrighted headers in the build tree (so reimplementation)
> 
> Sure, this is a primary goal for us.  This doesn't mean that user
> can't use for her/him-self additional SDKs provided by MS within our
> toolchain.  As far as I learned are some user using for example the
> DIA SDK successful.
> 

Yes, MSDN comes into play a lot here.

>> * Uses Microsoft DLLs, rather than GNU DLLs, for key functions (is this true 
>> anymore?)
> 
> For platform-functions we have to use OS provided DLLs, which are of
> course provided by MS.  For C-runtime we are using by default the
> msvcrt.dll - this is a big subject and might need additional comments
> as there are huge version-differences present - version. But of course
> it is possible to build applications using different MS runtimes, like
> msvcr100.dll, msvcr80.dll, etc. We don't use those DLLs by default, as
> they aren't part of the standard-OS DLL set.
> There are additional DLLs - and were ever for gcc/g++ based toolchains
> - which are provided by the toolchain.  Typical libraries provided by
> gcc are libgcc, libgfortran, libstdc++, libquadmath, libssp.
> Those DLLs can be used, but you have then of course to redistribute
> them to end-user for running your build app.  A way to avoid this is
> to use static version of those libraries.  This avoids dependencies to
> none-system DLLs in general - see -static options.
> If you plan to use a different runtime DLL, you might be in need to
> rebuild those gcc-target libraries, as they are build by most
> pre-compiled toolchains only using msvcrt.dll (Side note that static
> versions of gcc's libraries don't need to be rebuild here).
> 

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.

>> * Compiles both Windows Threads and POSIX threads (true?)
> 
> Yes, that true if you are using a pthread library. There is
> pthreads-win32 venture, or you can use winpthread - a mingw-w64 owned
> sub-project - for this.  By using winpthread you are able to build
> gcc's target-libraries in POSIX-way.
> 

Kai means the openMP implementation, yes you still can choose between
win32 threads and Posix threads in your applications if you use them
directly, though it is not a good idea to mix them.

>> * Equally produces static-linked and dynamic-linked binaries (this is VITAL 
>> for incident response.  The problem is that many of the packets in the 
>> repositories include dynamic versions but not static versions)
> 
> Sure, dynamic and static libraries are provided.  The issue about
> static-version is in some cases the used license for them.  For gcc's
> runtime-libraries there aren't any issues, as there is a
> runtime-exception present, but for other libraries there might be
> problems inflicted by license.  Eg (L)GPL's viral effect on license.
> 

I think this is more of a buildsystem issue rather than something
mingw-w64 specific. Look at autotools and 

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

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 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 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 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

[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

[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

[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

[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

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] 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Corinna Vinschen]

On Oct 26 21:11, Herb Thompson wrote:
> 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?

Per GPLv2 and v3, this requires a *written* offer to provide the
source code when asked for.  GPLv3 also restricts this right even
more, see
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html, section 3b.
https://www.gnu.org/licenses/gpl.html, section 6c (and 6b).

So, usually you provide source code in a public place.

I'm still puzzled, though, why providing source code is such a hassle,
apparently.  After all, this is called open source for a reason.

Again, for the third time, Open Source is *not* made for the developer
in the first place.  The idea is to grant the *user* the right to access
the source code of the application she's using, and the GPL is designed
this way to make sure that this right isn't conveniently forgotten along
the way, just because a developer is too lazy (and we devs *are* lazy,
isn't it?) to create a neat source package and to upload it in a
*visible* way to the same place as the object package.

> > 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.

GPLv2 is older than the Internet.  At the time the idea of bulk data
interchange was more or less restricted to physical media.  Read section
3 of the "terms and conditions for copying" here:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Today a "medium customarily used for software interchange" is the
Internet.  If you pull the binary ISO from the Fedora project page,
everything's ok if you also can pull the source packages from the same
page.  Or, FWIW, it's mirrors.


Corinna

--
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

[JonY]

On 10/27/2012 19:33, Corinna Vinschen wrote:
> On Oct 26 21:11, Herb Thompson wrote:
>> 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?
> 
> Per GPLv2 and v3, this requires a *written* offer to provide the
> source code when asked for.  GPLv3 also restricts this right even
> more, see
> https://www.gnu.org/licenses/old-licenses/gpl-2.0.html, section 3b.
> https://www.gnu.org/licenses/gpl.html, section 6c (and 6b).
> 
> So, usually you provide source code in a public place.
> 
> I'm still puzzled, though, why providing source code is such a hassle,
> apparently.  After all, this is called open source for a reason.
> 
> Again, for the third time, Open Source is *not* made for the developer
> in the first place.  The idea is to grant the *user* the right to access
> the source code of the application she's using, and the GPL is designed
> this way to make sure that this right isn't conveniently forgotten along
> the way, just because a developer is too lazy (and we devs *are* lazy,
> isn't it?) to create a neat source package and to upload it in a
> *visible* way to the same place as the object package.

This. Unfortunately some developers too have some entitlement issues,
too many think Free means do whatever you want, including enslaving the
downstream users, not sharing the Freedom they received.

Sure, other licenses have their uses in other areas, but with GPL, the
beauty of it is that it does not allow such hypocrisy.




signature.asc
Description: OpenPGP digital signature
--
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

[Peter Schaefer]

Am 10/27/2012 1:33 PM, Corinna Vinschen wrote:

(just 2c from a mingw-w64 user)

> I'm still puzzled, though, why providing source code is such a hassle,
> apparently.  After all, this is called open source for a reason.

It's not a hassle per se, but at least a bit unexpected that just
by using mingw-w64 to compile a, say, 600K binary and distributing
that, i need to ship (and/or version control and store) the 126MB
zipped toolchain sources, too.

As a happy Mingw-w64 user i since was under the impression that
following "COPYING.MinGW-w64-runtime.txt" is enough (which starts
liberal, but then also raises some questions in me regarding this
'FIXME: Cephes math lib' part and the LGPL WINE licensing).

I also misinterpreted the "combined work" aspect of the library
exception in a way that my program, libgcc and libstdc++ that i
install together in the app directory form the "combined work"
that "would otherwise violate the terms of GPLv3" and i'm free
to "convey such a combination under terms of (my) choice".

IMHO, the "COPYING.MinGW-w64-runtime.txt" should at least give an
additional hint regarding the GPLed GCC components.

Not everybody comes away with static linking only, once your
program is made of several executables and shared libs, you
want/need to have libgcc and libstd++ shared, too.

Regards,
   Peter

--
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?

[NightStrike]

On Wed, Oct 24, 2012 at 3:19 PM, Kai Tietz  wrote:
> Hello everybody,
>
> I want to raise this discussion on public mailing-list, as mingw-w64's
> release-cycle might be also of interest to some of our users.  Right
> now we do the major-release by gut feeling with a background plan
> about features new version shall include.   Now I got the request to
> do major release like some other ventures - eg gcc, binutils - after a
> fixed time-line.  For example if we would decide for a one-year
> release-cycle, it would Mean that we work about 6 - 8 months on new
> features, then we switch to stabelizing phase for 3 months, and then
> doing major-version branching and doing just bug-fixing on that
> branch.
> Another approach would be to do branching only if we are
> feature-complete for one version.  That of course means we should
> switch from gut-feeling to more detailed feature-plan.
>
> 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.

It probably makes the most sense to make a release when a new feature
goes into the stable branch.  We don't do enough work to justify
following the gcc timeline model (which in actuality is not time based
anyway).  For comparison purposes, gcc gets between 50 and 150 svn
commits a day.  We see 5-10.  We are a small project.

We should focus on features.  If I'm working on feature X, when that's
done should be the trigger for a release.  Each feature will trigger
its own release, within reason (obviously if two people put their
features into stable at the same time, you don't need two releases...)
 The point is that we aren't churning out new features every week or
month.

Now that said we could definitely benefit from higher
visibility as to what features are in the works.  That way, the
release manager (Ozkan) can know what's coming and what he should be
waiting for.  For instance, he'll be able to decide what to do when no
feature is in the pipeline for an amount of time, and maybe he wants
to checkpoint things after 6 months.

We need the flexibility to make releases when appropriate.

--
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?

[K. Frank]

Hello Kai!

On Wed, Oct 24, 2012 at 3:19 PM, Kai Tietz  wrote:
> Hello everybody,
>
> I want to raise this discussion on public mailing-list, as mingw-w64's
> release-cycle might be also of interest to some of our users.  Right
> now we do the major-release by gut feeling with a background plan
> about features new version shall include.   Now I got the request to
> do major release like some other ventures - eg gcc, binutils - after a
> fixed time-line.  For example if we would decide for a one-year
> release-cycle, it would Mean that we work about 6 - 8 months on new
> features, then we switch to stabelizing phase for 3 months, and then
> doing major-version branching and doing just bug-fixing on that
> branch.
> Another approach would be to do branching only if we are
> feature-complete for one version.  That of course means we should
> switch from gut-feeling to more detailed feature-plan.
>
> 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.

I'm just one guy, so don't give my opinion too much weight.  But
since you ask, I will chime in with my view.  (I use mingw-w64
primarily for personal experimental programming, rather than in a
production environment.)

I'm perfectly happy with your by-gut-feeling release cycle, and I think
it's probably the best way to go with this particular project.

You guys know what you're working on and you have a sense what's
more important and less important.  You also get a sense from this
list what your users are looking for:  "Not urgent, but give us a shout
when XXX becomes available." vs. "Ouch!  Bug YYY is really killing
me.  I hope we can get it fixed sooner rather than later."

So I vote for your judgement, rather than a mechanical (and artificial)
release cycle.

And thanks to all for tackling the project in the first place.

> Regards,
> Kai

Best.


K. Frank

--
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?

[Ruben Van Boxem]

2012/10/24 Kai Tietz 

> Hello everybody,
>
> I want to raise this discussion on public mailing-list, as mingw-w64's
> release-cycle might be also of interest to some of our users.  Right
> now we do the major-release by gut feeling with a background plan
> about features new version shall include.   Now I got the request to
> do major release like some other ventures - eg gcc, binutils - after a
> fixed time-line.  For example if we would decide for a one-year
> release-cycle, it would Mean that we work about 6 - 8 months on new
> features, then we switch to stabelizing phase for 3 months, and then
> doing major-version branching and doing just bug-fixing on that
> branch.
> Another approach would be to do branching only if we are
> feature-complete for one version.  That of course means we should
> switch from gut-feeling to more detailed feature-plan.
>
> 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.
>

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.

In my opinion, it would have been better to have had a release for the
"finished" features, so that they can at least reach a wider audience (be
honest: not all bugs can get squished when the code is exposed to a limited
number of users in trunk). So unless some new feature breaks old features
(which is a very vague criterion, I know) release early and often. This
will increase my "workload" in building toolchains, but heck, people like
regular updates if they know things are getting cooler.

For that matter, I'm getting the psychic hunch that winpthreads integration
into the crt is waiting for v3 to be released :P

A small pure development sidenote: I know it's possible for new features to
be developed first on a separate branch and later merged in. This is even
easier with stuff like git branches. Would a feature-based release model
not be easier to accomplish if every new feature were separated on its own
branch?

Ruben


>
> Regards,
> Kai
>
>
> --
> 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 versions?

[JonY]

On 10/25/2012 15:04, Ruben Van Boxem wrote:
> 2012/10/24 Kai Tietz 
> 
>> Hello everybody,
>>
>> I want to raise this discussion on public mailing-list, as mingw-w64's
>> release-cycle might be also of interest to some of our users.  Right
>> now we do the major-release by gut feeling with a background plan
>> about features new version shall include.   Now I got the request to
>> do major release like some other ventures - eg gcc, binutils - after a
>> fixed time-line.  For example if we would decide for a one-year
>> release-cycle, it would Mean that we work about 6 - 8 months on new
>> features, then we switch to stabelizing phase for 3 months, and then
>> doing major-version branching and doing just bug-fixing on that
>> branch.
>> Another approach would be to do branching only if we are
>> feature-complete for one version.  That of course means we should
>> switch from gut-feeling to more detailed feature-plan.
>>
>> 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.
>>
> 
> 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.

> In my opinion, it would have been better to have had a release for the
> "finished" features, so that they can at least reach a wider audience (be
> honest: not all bugs can get squished when the code is exposed to a limited
> number of users in trunk). So unless some new feature breaks old features
> (which is a very vague criterion, I know) release early and often. This
> will increase my "workload" in building toolchains, but heck, people like
> regular updates if they know things are getting cooler.
> 
> For that matter, I'm getting the psychic hunch that winpthreads integration
> into the crt is waiting for v3 to be released :P
> 

Yes please, make it happen :)

> A small pure development sidenote: I know it's possible for new features to
> be developed first on a separate branch and later merged in. This is even
> easier with stuff like git branches. Would a feature-based release model
> not be easier to accomplish if every new feature were separated on its own
> branch?

Well, the problem with that is that branches tend to diverge if not
maintained. This can be a problem if multiple branches do some
incompatible changes and try to merge to trunk later.

I still prefer trunk to be the in-flux devel tree, we already have
branches for the stable stuff, managed finely by Ozkan thus far.





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 versions?

[NightStrike]

On Thu, Oct 25, 2012 at 3:04 AM, Ruben Van Boxem
 wrote:
> 2012/10/24 Kai Tietz 
>>
>> Hello everybody,
>>
>> I want to raise this discussion on public mailing-list, as mingw-w64's
>> release-cycle might be also of interest to some of our users.  Right
>> now we do the major-release by gut feeling with a background plan
>> about features new version shall include.   Now I got the request to
>> do major release like some other ventures - eg gcc, binutils - after a
>> fixed time-line.  For example if we would decide for a one-year
>> release-cycle, it would Mean that we work about 6 - 8 months on new
>> features, then we switch to stabelizing phase for 3 months, and then
>> doing major-version branching and doing just bug-fixing on that
>> branch.
>> Another approach would be to do branching only if we are
>> feature-complete for one version.  That of course means we should
>> switch from gut-feeling to more detailed feature-plan.
>>
>> 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.
>
>
> 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 you feel that a feature is ready for stable, then communicate that to Ozkan.

> In my opinion, it would have been better to have had a release for the
> "finished" features, so that they can at least reach a wider audience (be
> honest: not all bugs can get squished when the code is exposed to a limited
> number of users in trunk). So unless some new feature breaks old features
> (which is a very vague criterion, I know) release early and often. This will
> increase my "workload" in building toolchains, but heck, people like regular
> updates if they know things are getting cooler.

Agree -- we can achieve this with communication with the stable branch
maintainer.  Ozkan is very good at managing those branches.  We just
have to tell him if we want something.

> For that matter, I'm getting the psychic hunch that winpthreads integration
> into the crt is waiting for v3 to be released :P
>
> A small pure development sidenote: I know it's possible for new features to
> be developed first on a separate branch and later merged in. This is even
> easier with stuff like git branches. Would a feature-based release model not
> be easier to accomplish if every new feature were separated on its own
> branch?

That's what experimental is for.  You can do your own dirty work there
in whatever directory you want.

--
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?

[Jacek Caban]

On 10/24/12 21:19, Kai Tietz wrote:
> 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.

Current release-cycles strategy works fine for me, but now that you
mention it, it got me thinking and I realized that I do have different
opinion :) I feel like I'm both mingw-w64 developer (as in mingw-w64
contributor) and user (as in developer and maintainer of a project that
heavily depends on mingw-w64). Let me present both points of view (sorry
for the long mail):

* developer's point of view

I've never seen official release-cycle policy of the project and I
joined the project when it was already established, so I may be missing
something. Here is what I would expect from a model that has development
and stable branches:

- All development happens on the trunk. If stable branch needs a patch,
with very few exceptions, the patch is committed to the trunk and
cherry-picked.
- Stable branches see very limited activity. No new features, just
regression/bug fixes.

Now... that's not really what happens. Stable branches get all sorts of
new declarations, headers and *new* stuff in libraries. Those are not
regression fixes. After all, if mingw-w64 never had given function
declaration or header in the past, there is no way that the fact it is
missing is a regression.

That said, stable branches are in fact another development branches. I
myself don't see the point in it and that's why I don't care at all
about stable branches unless Ozkan explicitly ask for a backport (and
even then I trust he knows that it's safe, I don't test it myself). This
worked for me so far, so I'm fine with it, but this could be improved.

>From my experience, mingw-w64 has rather stable trunk. There were few
exceptions in the past but:
- As long as they are rare, that's fine
- We can do better at avoiding them (and in fact we do better than in
the past)
So, why not make releases 'lighter', more often, based on gut-feeling.
When we think it's been a (undefined) while and trunk is stable, ship
it. At this point we may create a branch, call it RC, do some efforts to
ensure it's stable, release and forget. Well... not really forget, if
there is a serious regression, we can do a bug-fix release based on that
branch, but other than that, the branch should not cost any more
efforts. If there is something worth giving to users, it may as well
wait for the next release. The next release would be relatively soon,
after all.

A few more words about ensuring stability: We mostly know what risky
changes have been made and we occasionally hear back from users when
something breaks. I myself would know quickly if something really bad
happened. I do Mozilla code base builds as cron nightly job and update
mingw-w64 every few days on that box. It exercises headers and crt
pretty heavily, so it's quite a compelling test. Now, if we had a few
such projects (eg. regular Qt builds) that we can easily ensure to be
working correctly before each release, that's a pretty good test case.
Buildbot would be great for that, but so would be active
users/developers that would test builds on regular basis, or at least
after tagging for RC. Same for packagers, if it could be coordinated
with them to ensure RC works for them, that's probably enough for release.

To conclude my proposal:
- We develop on trunk and don't care about other branches as long as we
don't have *regression* bugs (and only regression bugs)
- Every now and then when trunk is stable, we decide to do release
- At this point a branch is created and trunk is kept open for development
- In the release branch:
   - Prepare release notes (they don't need to be full of cool new
features, just describe what changes)
   - Tag for RC
   - Call for testing and fix eventual *regression* bugs
   - Tag for release, ship and forget about the branch (and eventually
come back to it when a serious regression happens)

This way users get all (not only selected few) changes quicker and
developers don't have to waste time on several branches. Also I believe
that efforts required for release kept as minimal as possible.

That's just my idea that materialized after reading Kai's mail, so it
may be pre-mature, but I like it:) Other's opinions are welcomed.


* user's point of view

I promised two points of view, here is the second. I maintain Wine Gecko
package, which is based on Mozilla codebase. Mozilla code is a very fast
moving target with rapid release cycles. Every release so far requires
at least some (sometimes a lot) fixes to mingw-w64. That said, I can't
guarantee much more than that Wine Gecko will work with current trunk.
In practice, due to code stabilisation on Mozilla side, it's usually a
bit longer period, usually about 12 weeks (when given version is in
alpha aka aurora and beta stage). That forces distros compiling the
source to follow trunk version, because releases are alm

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

[NightStrike]

On Thu, Oct 25, 2012 at 8:51 AM, Jacek Caban  wrote:
> On 10/24/12 21:19, Kai Tietz wrote:
>> 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.
>
> I've never seen official release-cycle policy of the project and I
> joined the project when it was already established, so I may be missing
> something. Here is what I would expect from a model that has development
> and stable branches:

This documents some things:
http://sourceforge.net/apps/trac/mingw-w64/wiki/VersionSpec

The rest has never made it from mailing list to wiki :(

--
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 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 versions?

[Erik van Pienbroek]

Kai Tietz schreef op wo 24-10-2012 om 21:19 [+0200]:
> Hello everybody,
> 
> I want to raise this discussion on public mailing-list, as mingw-w64's
> release-cycle might be also of interest to some of our users.  Right
> now we do the major-release by gut feeling with a background plan
> about features new version shall include.   Now I got the request to
> do major release like some other ventures - eg gcc, binutils - after a
> fixed time-line.  For example if we would decide for a one-year
> release-cycle, it would Mean that we work about 6 - 8 months on new
> features, then we switch to stabelizing phase for 3 months, and then
> doing major-version branching and doing just bug-fixing on that
> branch.
> Another approach would be to do branching only if we are
> feature-complete for one version.  That of course means we should
> switch from gut-feeling to more detailed feature-plan.
> 
> 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.

Hi,

Before I start I would like to point out that the points mentioned below
aren't meant as criticism, but they are areas which I think can
potentially be improved. For the TL;DR variant, see the bottom of this
mail for my conclusion

>From my packager/distributor point of view I would like to vouch for the
release-early-release-often strategy. This means more frequent
releases. 

Version 2.0 of mingw-w64 was already released over a year ago. In the
past year the v2 branch has seen several backports and several releases.
However, the difficult thing is that these new releases aren't announced
on the website or on the mailing list at all. This makes it hard for
packagers and other users to find out if a new version of mingw-w64 is
available. Also, if people want to know what has changed between
releases then they have are forced to check the SVN repo history.

Another thing that I consider is missing are unstable releases. In
Fedora RPM packages always need to have a version number and a release
number. For mingw-w64 releases based on the v2 branch this is simple
(for example: version=2.0.7, release=1). However as there are no
unstable mingw-w64 releases being created for the trunk branch (and we
in Fedora want to provide packages based on the trunk branch) we had to
invent our own version number in Fedora. We want to make sure that
whenever users want to update from the current trunk version to the
final 3.0 release (once it will be released) that RPM thinks that the
final 3.0 release is more recent than the current trunk version and
allows the update. Because of this reason we're currently building our
mingw-w64 packages using version=2.0.999 and release=0.1.trunk.20121023.
With this pattern users can see that we're using a trunk snapshot dated
20121023 and the upgrade path will work when mingw-w64 version 3.0 will
be released. In the end this custom version number is confusing to
end-users as on the mingw-w64 website there are no references to version
2.0.999. One way to solve this issue is to publish unstable releases
from time to time.

To sum it up I would like to propose the following:
* Publish unstable releases (from the trunk branch) periodically
  (this can be time based)
* Once the trunk has reached a certain level of stability/new
  set of features branch it and make a stable release
* When regressions are detected in a stable branch publish a
  new stable release
* Give more visibility to new releases on the website and the
  mailing list and include a global outline of the most important
  changes

A potential versioning scheme for this could be the GNOME one. They're
using uneven major version numbers to mark unstable releases (like
3.5.x) and even major version numbers to mark stable releases (like
3.6.x). Perhaps something similar can be used for mingw-w64 too

Kind regards,

Erik van Pienbroek





--
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?

[Erik van Pienbroek]

Jacek Caban schreef op do 25-10-2012 om 14:51 [+0200]:
> A few more words about ensuring stability: We mostly know what risky
> changes have been made and we occasionally hear back from users when
> something breaks. I myself would know quickly if something really bad
> happened. I do Mozilla code base builds as cron nightly job and update
> mingw-w64 every few days on that box. It exercises headers and crt
> pretty heavily, so it's quite a compelling test. Now, if we had a few
> such projects (eg. regular Qt builds) that we can easily ensure to be
> working correctly before each release, that's a pretty good test case.
> Buildbot would be great for that, but so would be active
> users/developers that would test builds on regular basis, or at least
> after tagging for RC. Same for packagers, if it could be coordinated
> with them to ensure RC works for them, that's probably enough for release.

Perhaps I can help in this area. In Fedora we currently have over 125
different mingw packages and we are frequently pushing updated mingw-w64
trunk snapshots to the Fedora development branch. I could try to write a
script which tries to mass rebuild all these packages against recent
mingw-w64 snapshots and report any breakage automatically. This script
could then be run periodically (say once every week) so regressions can
be spotted relatively soon. For this I need to find one or more machines
where this script can be executed periodically but that shouldn't be too
hard of a problem.

Kind regards,

Erik van Pienbroek



--
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?

[JonY]

On 10/28/2012 06:01, Erik van Pienbroek wrote:
> Jacek Caban schreef op do 25-10-2012 om 14:51 [+0200]:
>> A few more words about ensuring stability: We mostly know what risky
>> changes have been made and we occasionally hear back from users when
>> something breaks. I myself would know quickly if something really bad
>> happened. I do Mozilla code base builds as cron nightly job and update
>> mingw-w64 every few days on that box. It exercises headers and crt
>> pretty heavily, so it's quite a compelling test. Now, if we had a few
>> such projects (eg. regular Qt builds) that we can easily ensure to be
>> working correctly before each release, that's a pretty good test case.
>> Buildbot would be great for that, but so would be active
>> users/developers that would test builds on regular basis, or at least
>> after tagging for RC. Same for packagers, if it could be coordinated
>> with them to ensure RC works for them, that's probably enough for release.
> 
> Perhaps I can help in this area. In Fedora we currently have over 125
> different mingw packages and we are frequently pushing updated mingw-w64
> trunk snapshots to the Fedora development branch. I could try to write a
> script which tries to mass rebuild all these packages against recent
> mingw-w64 snapshots and report any breakage automatically. This script
> could then be run periodically (say once every week) so regressions can
> be spotted relatively soon. For this I need to find one or more machines
> where this script can be executed periodically but that shouldn't be too
> hard of a problem.
> 
> Kind regards,
> 
> Erik van Pienbroek

Does that include several large C++ programs? I need to test a patch for
trunk headers.

If so, I can push in the less invasive change and hopefully it should
not affect any builds.




signature.asc
Description: OpenPGP digital signature
--
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?

[Erik van Pienbroek]

JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
> Does that include several large C++ programs? I need to test a patch for
> trunk headers.
> 
> If so, I can push in the less invasive change and hopefully it should
> not affect any builds.

Yes, we also provide various large C++ libraries, like for example
boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
(Qt5 isn't yet on that list as those packages are still under review,
but I can already pull them in for local mass rebuilds)



--
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?

[JonY]

On 10/28/2012 18:33, Erik van Pienbroek wrote:
> JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
>> Does that include several large C++ programs? I need to test a patch for
>> trunk headers.
>>
>> If so, I can push in the less invasive change and hopefully it should
>> not affect any builds.
> 
> Yes, we also provide various large C++ libraries, like for example
> boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
> https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
> (Qt5 isn't yet on that list as those packages are still under review,
> but I can already pull them in for local mass rebuilds)
> 

I have a patch that makes C++11 std::to_{w,}string work, it's working
right now, I'm just not sure if there are any bad side effects, which is
where C++ library builds come into play.

Right now, patch is waiting for final OK from Kai, I'll ping again when
the patch makes it in.





signature.asc
Description: OpenPGP digital signature
--
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?

[Erik van Pienbroek]

JonY schreef op zo 28-10-2012 om 19:08 [+0800]:
> On 10/28/2012 18:33, Erik van Pienbroek wrote:
> > JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
> >> Does that include several large C++ programs? I need to test a patch for
> >> trunk headers.
> >>
> >> If so, I can push in the less invasive change and hopefully it should
> >> not affect any builds.
> > 
> > Yes, we also provide various large C++ libraries, like for example
> > boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
> > https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
> > (Qt5 isn't yet on that list as those packages are still under review,
> > but I can already pull them in for local mass rebuilds)
> > 
> 
> I have a patch that makes C++11 std::to_{w,}string work, it's working
> right now, I'm just not sure if there are any bad side effects, which is
> where C++ library builds come into play.
> 
> Right now, patch is waiting for final OK from Kai, I'll ping again when
> the patch makes it in.

Okay, Qt5 is built using C++11 by default, so we can use that to test
your patch


--
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?

[Kai Tietz]

2012/10/28 Erik van Pienbroek :
> JonY schreef op zo 28-10-2012 om 19:08 [+0800]:
>> On 10/28/2012 18:33, Erik van Pienbroek wrote:
>> > JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
>> >> Does that include several large C++ programs? I need to test a patch for
>> >> trunk headers.
>> >>
>> >> If so, I can push in the less invasive change and hopefully it should
>> >> not affect any builds.
>> >
>> > Yes, we also provide various large C++ libraries, like for example
>> > boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
>> > https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
>> > (Qt5 isn't yet on that list as those packages are still under review,
>> > but I can already pull them in for local mass rebuilds)
>> >
>>
>> I have a patch that makes C++11 std::to_{w,}string work, it's working
>> right now, I'm just not sure if there are any bad side effects, which is
>> where C++ library builds come into play.
>>
>> Right now, patch is waiting for final OK from Kai, I'll ping again when
>> the patch makes it in.
>
> Okay, Qt5 is built using C++11 by default, so we can use that to test
> your patch

Ok, JonY. so you can apply this patch to trunk.  If things cause
problems then please revert it again.

Cheers,
Kai

--
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?

[JonY]

On 10/28/2012 21:16, Kai Tietz wrote:
> 2012/10/28 Erik van Pienbroek :
>> JonY schreef op zo 28-10-2012 om 19:08 [+0800]:
>>> On 10/28/2012 18:33, Erik van Pienbroek wrote:
 JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
> Does that include several large C++ programs? I need to test a patch for
> trunk headers.
>
> If so, I can push in the less invasive change and hopefully it should
> not affect any builds.

 Yes, we also provide various large C++ libraries, like for example
 boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
 https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
 (Qt5 isn't yet on that list as those packages are still under review,
 but I can already pull them in for local mass rebuilds)

>>>
>>> I have a patch that makes C++11 std::to_{w,}string work, it's working
>>> right now, I'm just not sure if there are any bad side effects, which is
>>> where C++ library builds come into play.
>>>
>>> Right now, patch is waiting for final OK from Kai, I'll ping again when
>>> the patch makes it in.
>>
>> Okay, Qt5 is built using C++11 by default, so we can use that to test
>> your patch
> 
> Ok, JonY. so you can apply this patch to trunk.  If things cause
> problems then please revert it again.

Thanks.

OK, now in trunk, it should not affect anything unless, you went into
GCC c++ os_defines.h to comment out _GLIBCXX_HAVE_BROKEN_VSWPRINTF. So,
no new features, no breakages unless you changed some GCC headers.

Here's the relevant macro guard for the ISO compliant vswprintf in
stdio.h and wchar.h:
#if defined(__cplusplus) && (__cplusplus >= 201103L) &&
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)

Kai, I think it should be fine to poke upstream GCC trunk to remove the
_GLIBCXX_HAVE_BROKEN_VSWPRINTF from the mingw-w64 os_defines.h in libstdc++.




signature.asc
Description: OpenPGP digital signature
--
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?

[Kai Tietz]

JonY,

please sent patch upstream to gcc's and libstdc++'s ML.  Add me CC and
please mention that I ok'ed patch on IRC.  I won't be able to reply
next week myself.

Cheers,
Kai

2012/10/28 JonY :
> On 10/28/2012 21:16, Kai Tietz wrote:
>> 2012/10/28 Erik van Pienbroek :
>>> JonY schreef op zo 28-10-2012 om 19:08 [+0800]:
 On 10/28/2012 18:33, Erik van Pienbroek wrote:
> JonY schreef op zo 28-10-2012 om 10:42 [+0800]:
>> Does that include several large C++ programs? I need to test a patch for
>> trunk headers.
>>
>> If so, I can push in the less invasive change and hopefully it should
>> not affect any builds.
>
> Yes, we also provide various large C++ libraries, like for example
> boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
> https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
> (Qt5 isn't yet on that list as those packages are still under review,
> but I can already pull them in for local mass rebuilds)
>

 I have a patch that makes C++11 std::to_{w,}string work, it's working
 right now, I'm just not sure if there are any bad side effects, which is
 where C++ library builds come into play.

 Right now, patch is waiting for final OK from Kai, I'll ping again when
 the patch makes it in.
>>>
>>> Okay, Qt5 is built using C++11 by default, so we can use that to test
>>> your patch
>>
>> Ok, JonY. so you can apply this patch to trunk.  If things cause
>> problems then please revert it again.
>
> Thanks.
>
> OK, now in trunk, it should not affect anything unless, you went into
> GCC c++ os_defines.h to comment out _GLIBCXX_HAVE_BROKEN_VSWPRINTF. So,
> no new features, no breakages unless you changed some GCC headers.
>
> Here's the relevant macro guard for the ISO compliant vswprintf in
> stdio.h and wchar.h:
> #if defined(__cplusplus) && (__cplusplus >= 201103L) &&
> !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
>
> Kai, I think it should be fine to poke upstream GCC trunk to remove the
> _GLIBCXX_HAVE_BROKEN_VSWPRINTF from the mingw-w64 os_defines.h in libstdc++.
>
>
>
> --
> 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
>



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

--
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?

[NightStrike]

On Sat, Oct 27, 2012 at 11:49 AM, Erik van Pienbroek
 wrote:
> To sum it up I would like to propose the following:
> * Publish unstable releases (from the trunk branch) periodically
>   (this can be time based)

Are you volunteering for this?  Right now, we only have one release
manager.  We're a small project, remember, not a big one.  Smaller
projects don't need all of the overhead / work / organization that a
bigger project (say, Fedora) would need or can afford to maintain.

--
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?

[JonY]

On 10/29/2012 01:30, Kai Tietz wrote:
> JonY,
> 
> please sent patch upstream to gcc's and libstdc++'s ML.  Add me CC and
> please mention that I ok'ed patch on IRC.  I won't be able to reply
> next week myself.
> 
> Cheers,
> Kai
> 

OK, it's in, but I forgot to announce it.

To use std::to_string and std::to_wstring, you will need trunk GCC (at
least r193033) and CRT (at least r5437).

when in C++11 mode, vswprintf will behave as the ISO standard
implementation with 4 args, unlike the MS variant which has 3 args.

Using trunk CRT without meeting the minimum GCC version should have no
effect, vswprintf will still have 3 arguments in C++11 mode.

GCC trunk libstdc++ will likely not build unless you also meet the CRT
requirements.

Ozkan, should this be backported to 2.x branch?







signature.asc
Description: OpenPGP digital signature
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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?

[Ozkan Sezer]

On 11/5/12, JonY  wrote:
> On 10/29/2012 01:30, Kai Tietz wrote:
>> JonY,
>>
>> please sent patch upstream to gcc's and libstdc++'s ML.  Add me CC and
>> please mention that I ok'ed patch on IRC.  I won't be able to reply
>> next week myself.
>>
>> Cheers,
>> Kai
>>
>
> OK, it's in, but I forgot to announce it.
>
> To use std::to_string and std::to_wstring, you will need trunk GCC (at
> least r193033) and CRT (at least r5437).
>
> when in C++11 mode, vswprintf will behave as the ISO standard
> implementation with 4 args, unlike the MS variant which has 3 args.
>
> Using trunk CRT without meeting the minimum GCC version should have no
> effect, vswprintf will still have 3 arguments in C++11 mode.
>
> GCC trunk libstdc++ will likely not build unless you also meet the CRT
> requirements.
>
> Ozkan, should this be backported to 2.x branch?

If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
please go ahead.

--
O.S.

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
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 11/5/2012 20:44, Ozkan Sezer wrote:
> 
> If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
> please go ahead.

When you put it that way, it suddenly hit me that the vfwsprintf will
not really work if the user set -std=c++11 without including any C++
headers first. Such as when the use include  directly.

Any suggestions? The guard macro is:

#if defined(__cplusplus) && (__cplusplus >= 201103L) &&
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)

_GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including
some basic C++ headers.

Basically, I didn't want users to be caught surprised. Any changes would
be on the mingw-w64 side, since the gcc change was just removing
_GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used.





signature.asc
Description: OpenPGP digital signature
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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?

[Ruben Van Boxem]

2012/11/5 JonY 

> On 11/5/2012 20:44, Ozkan Sezer wrote:
> >
> > If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
> > please go ahead.
>
> When you put it that way, it suddenly hit me that the vfwsprintf will
> not really work if the user set -std=c++11 without including any C++
> headers first. Such as when the use include  directly.
>
> Any suggestions? The guard macro is:
>
> #if defined(__cplusplus) && (__cplusplus >= 201103L) &&
> !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
>
> _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including
> some basic C++ headers.
>
> Basically, I didn't want users to be caught surprised. Any changes would
> be on the mingw-w64 side, since the gcc change was just removing
> _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used.
>

The way it would work now, the declaration of a C function would depend on
the C++ standard in effect. This is mildly worrying and very unexpected.

How much trouble would it be to only have the std::vswprintf work in a C99
way, and leave ::vswprintf as the broken C function. This would require
accommodation by libstdc++ (not sure how receptive they are for these kinds
of changes), and would at least provide a consistent declaration of the C
function.

Ruben



>
>
>
>
>
> --
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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 11/5/2012 21:16, Ruben Van Boxem wrote:
> 2012/11/5 JonY 
> 
>> On 11/5/2012 20:44, Ozkan Sezer wrote:
>>>
>>> If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
>>> please go ahead.
>>
>> When you put it that way, it suddenly hit me that the vfwsprintf will
>> not really work if the user set -std=c++11 without including any C++
>> headers first. Such as when the use include  directly.
>>
>> Any suggestions? The guard macro is:
>>
>> #if defined(__cplusplus) && (__cplusplus >= 201103L) &&
>> !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
>>
>> _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including
>> some basic C++ headers.
>>
>> Basically, I didn't want users to be caught surprised. Any changes would
>> be on the mingw-w64 side, since the gcc change was just removing
>> _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used.
>>
> 
> The way it would work now, the declaration of a C function would depend on
> the C++ standard in effect. This is mildly worrying and very unexpected.
> 
> How much trouble would it be to only have the std::vswprintf work in a C99
> way, and leave ::vswprintf as the broken C function. This would require
> accommodation by libstdc++ (not sure how receptive they are for these kinds
> of changes), and would at least provide a consistent declaration of the C
> function.

They aren't really accepting of OS specific hacks.





signature.asc
Description: OpenPGP digital signature
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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?

[Ruben Van Boxem]

2012/11/5 JonY 

> On 11/5/2012 21:16, Ruben Van Boxem wrote:
> > 2012/11/5 JonY 
> >
> >> On 11/5/2012 20:44, Ozkan Sezer wrote:
> >>>
> >>> If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
> >>> please go ahead.
> >>
> >> When you put it that way, it suddenly hit me that the vfwsprintf will
> >> not really work if the user set -std=c++11 without including any C++
> >> headers first. Such as when the use include  directly.
> >>
> >> Any suggestions? The guard macro is:
> >>
> >> #if defined(__cplusplus) && (__cplusplus >= 201103L) &&
> >> !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
> >>
> >> _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including
> >> some basic C++ headers.
> >>
> >> Basically, I didn't want users to be caught surprised. Any changes would
> >> be on the mingw-w64 side, since the gcc change was just removing
> >> _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used.
> >>
> >
> > The way it would work now, the declaration of a C function would depend
> on
> > the C++ standard in effect. This is mildly worrying and very unexpected.
> >
> > How much trouble would it be to only have the std::vswprintf work in a
> C99
> > way, and leave ::vswprintf as the broken C function. This would require
> > accommodation by libstdc++ (not sure how receptive they are for these
> kinds
> > of changes), and would at least provide a consistent declaration of the C
> > function.
>
> They aren't really accepting of OS specific hacks.
>

IMHO, that's just stupid. A C++ library is a layer atop an OS. There's
bound to be incompatibilities. If they're not willing to have OS specific
things in their code, why check for every damn function you use and work
around missing ones?
/rant

Off-topic: getting LLVM libc++ to work with GCC might be feasible, the only
real problem is that GCC's libsupc++ contains stuff also in libc++, so
there'd need to be a custom "libsupc++" library providing only those things
not in libc++, who are very willing to accept OS specific hacks if
implemented transparently. And then just hope GCC is up to the task of
parsing a bunch of advanced C++11 template magic used in libc++ type_traits.
/rant/rant

I'll stop now. I swear :)

Ruben


>
>
>
>
> --
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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 11/5/2012 21:31, Ruben Van Boxem wrote:
> 2012/11/5 JonY 
> 
>> On 11/5/2012 21:16, Ruben Van Boxem wrote:
>>> 2012/11/5 JonY 
>>>
 On 11/5/2012 20:44, Ozkan Sezer wrote:
>
> If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then
> please go ahead.

 When you put it that way, it suddenly hit me that the vfwsprintf will
 not really work if the user set -std=c++11 without including any C++
 headers first. Such as when the use include  directly.

 Any suggestions? The guard macro is:

 #if defined(__cplusplus) && (__cplusplus >= 201103L) &&
 !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)

 _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including
 some basic C++ headers.

 Basically, I didn't want users to be caught surprised. Any changes would
 be on the mingw-w64 side, since the gcc change was just removing
 _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used.

>>>
>>> The way it would work now, the declaration of a C function would depend
>> on
>>> the C++ standard in effect. This is mildly worrying and very unexpected.
>>>
>>> How much trouble would it be to only have the std::vswprintf work in a
>> C99
>>> way, and leave ::vswprintf as the broken C function. This would require
>>> accommodation by libstdc++ (not sure how receptive they are for these
>> kinds
>>> of changes), and would at least provide a consistent declaration of the C
>>> function.
>>
>> They aren't really accepting of OS specific hacks.
>>
> 
> IMHO, that's just stupid. A C++ library is a layer atop an OS. There's
> bound to be incompatibilities. If they're not willing to have OS specific
> things in their code, why check for every damn function you use and work
> around missing ones?
> /rant

Actually, according to
http://msdn.microsoft.com/en-us/library/28d5ce15%28v=vs.80%29.aspx

In Visual C++ 2005, vswprintf conforms to the ISO C Standard, which
requires the second parameter, count, of type size_t. To force the old
nonstandard behavior, define _CRT_NON_CONFORMING_SWPRINTFS. The old
behavior may not be in a future version, so code should be changed to
use the new conformant behavior.

We do that to mingw-w64 too? MSVC has this behavior since 2005.

Obviously it will break if user defines _CRT_NON_CONFORMING_SWPRINTFS
and C++11 at the same time, but that would be PEBCAK.





signature.asc
Description: OpenPGP digital signature
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
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 11/6/2012 16:57, JonY wrote:
> 
> Actually, according to
> http://msdn.microsoft.com/en-us/library/28d5ce15%28v=vs.80%29.aspx
> 
> In Visual C++ 2005, vswprintf conforms to the ISO C Standard, which
> requires the second parameter, count, of type size_t. To force the old
> nonstandard behavior, define _CRT_NON_CONFORMING_SWPRINTFS. The old
> behavior may not be in a future version, so code should be changed to
> use the new conformant behavior.
> 
> We do that to mingw-w64 too? MSVC has this behavior since 2005.
> 
> Obviously it will break if user defines _CRT_NON_CONFORMING_SWPRINTFS
> and C++11 at the same time, but that would be PEBCAK.
> 
> 

Alright new patch attached.

Tested with _CRT_NON_CONFORMING_SWPRINTFS and __USE_MINGW_ANSI_STDIO on
and off.

Comments?

Index: stdio.h
===
--- stdio.h (revision 5439)
+++ stdio.h (working copy)
@@ -632,6 +632,10 @@
 #define __mingw_ovr static __cdecl
 #endif
 
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS) && defined(__cplusplus) && 
(__cplusplus >= 201103L)
+#error "_CRT_NON_CONFORMING_SWPRINTFS cannot be used with C++11 or later."
+#endif /* defined(_CRT_NON_CONFORMING_SWPRINTFS) && defined(__cplusplus) && 
(__cplusplus >= 201103L) */
+
 #if __USE_MINGW_ANSI_STDIO
 /*
  * User has expressed a preference for C99 conformance...
@@ -742,8 +746,7 @@
   return __mingw_vwprintf( __format, __local_argv );
 }
 
-/* For libstdc++ */
-#if defined(__cplusplus) && (__cplusplus >= 201103L) && 
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS)
 __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)
@@ -757,7 +760,7 @@
 {
   return __mingw_vswprintf( __stream, __format, __local_argv );
 }
-#endif /* defined(__cplusplus) && (__cplusplus >= 201103L) && 
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) */
+#endif /* !defined(_CRT_NON_CONFORMING_SWPRINTFS) */
 
 #ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
 __mingw_ovr
@@ -816,7 +819,9 @@
   int __cdecl vfwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__ 
_Format,va_list _ArgList);
   int __cdecl vwprintf(const wchar_t * __restrict__ _Format,va_list _ArgList);
   _CRTIMP int __cdecl swprintf(wchar_t * __restrict__ , const wchar_t * 
__restrict__ , ...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS)
   _CRTIMP int __cdecl vswprintf(wchar_t * __restrict__ , const wchar_t * 
__restrict__ ,va_list) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+#endif /*!_CRT_NON_CONFORMING_SWPRINTFS*/
 #endif /* __USE_MINGW_ANSI_STDIO */
 
 #ifndef WEOF
@@ -850,6 +855,11 @@
   _CRTIMP int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t 
_Count,const wchar_t * __restrict__ _Format,...) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
   _CRTIMP int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t 
_Count,const wchar_t * __restrict__ _Format,va_list _Args) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS) && !defined(__USE_MINGW_ANSI_STDIO)
+  __mingw_ovr int __cdecl vswprintf(wchar_t * __restrict__ _Dest,size_t 
_Count,const wchar_t * __restrict__ _Format,va_list _Args) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN{
+return _vsnwprintf(_Dest,_Count,_Format,_Args);
+  }
+#endif /* !defined(_CRT_NON_CONFORMING_SWPRINTFS) */
 #ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
 
 #if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
@@ -913,7 +923,6 @@
 #ifdef _CRT_NON_CONFORMING_SWPRINTFS
 #ifndef __cplusplus
 #define swprintf _swprintf
-#define vswprintf _vswprintf
 #define _swprintf_l __swprintf_l
 #define _vswprintf_l __vswprintf_l
 #endif
Index: wchar.h
===
--- wchar.h (revision 5439)
+++ wchar.h (working copy)
@@ -458,6 +458,10 @@
 #define __mingw_ovr static __cdecl
 #endif
 
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS) && defined(__cplusplus) && 
(__cplusplus >= 201103L)
+#error "_CRT_NON_CONFORMING_SWPRINTFS cannot be used with C++11 or later."
+#endif /* defined(_CRT_NON_CONFORMING_SWPRINTFS) && defined(__cplusplus) && 
(__cplusplus >= 201103L) */
+
 #if __USE_MINGW_ANSI_STDIO
 
 /*
@@ -568,8 +572,7 @@
   return __mingw_vwprintf( __format, __local_argv );
 }
 
-/* For libstdc++ */
-#if defined(__cplusplus) && (__cplusplus >= 201103L) && 
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS)
 __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)
@@ -583,7 +586,7 @@
 {
   return __mingw_vswprintf( __stream, __format, __local_argv );
 }
-#endif /* defined(__cplusplus) && (__cplusplus >= 201103L) && 
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) */
+#endif /* !defined(_CRT_NON_CONFORM

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

[Erik van Pienbroek]

Erik van Pienbroek schreef op zo 28-10-2012 om 00:01 [+0200]:
> I could try to write a
> script which tries to mass rebuild all these packages against recent
> mingw-w64 snapshots and report any breakage automatically

Hi,

In the last couple of days I've been working on a mass rebuild script
which can be run fully automatic and which can create a report about the
results. An initial mass rebuild report was just sent to the
fedora-mingw mailing list, but if you guys here are interested in it as
well I can also forward it to this list in the future.

The report can be found at
http://lists.fedoraproject.org/pipermail/mingw/2012-November/005884.html

The next report (which I expect to generate in a couple of days) will
also include a comparison to the previous mass rebuild (i.e. which
packages failed to build but succeeded during the previous mass
rebuild), a list of all newly added packages (if any) and a list of all
changes which were applied in the Fedora MinGW packages (including
updates to the mingw-w64 toolchain). An example for such a complete
report can be found at http://fpaste.org/1kuz/

Kind regards,

Erik van Pienbroek



--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
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?

[Ozkan Sezer]

On 11/7/12, Erik van Pienbroek  wrote:
> Erik van Pienbroek schreef op zo 28-10-2012 om 00:01 [+0200]:
>> I could try to write a
>> script which tries to mass rebuild all these packages against recent
>> mingw-w64 snapshots and report any breakage automatically
>
> Hi,
>
> In the last couple of days I've been working on a mass rebuild script
> which can be run fully automatic and which can create a report about the
> results. An initial mass rebuild report was just sent to the
> fedora-mingw mailing list, but if you guys here are interested in it as
> well I can also forward it to this list in the future.
>
> The report can be found at
> http://lists.fedoraproject.org/pipermail/mingw/2012-November/005884.html
>

Nice to see that only 3 packages failed build and none of the failures
are actually mingw[-w64]-related.

> The next report (which I expect to generate in a couple of days) will
> also include a comparison to the previous mass rebuild (i.e. which
> packages failed to build but succeeded during the previous mass
> rebuild), a list of all newly added packages (if any) and a list of all
> changes which were applied in the Fedora MinGW packages (including
> updates to the mingw-w64 toolchain). An example for such a complete
> report can be found at http://fpaste.org/1kuz/
>
> Kind regards,
>
> Erik van Pienbroek
>

--
O.S.

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
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?

[Jacek Caban]

On 11/07/12 21:27, Erik van Pienbroek wrote:
> Erik van Pienbroek schreef op zo 28-10-2012 om 00:01 [+0200]:
>> I could try to write a
>> script which tries to mass rebuild all these packages against recent
>> mingw-w64 snapshots and report any breakage automatically
> Hi,
>
> In the last couple of days I've been working on a mass rebuild script
> which can be run fully automatic and which can create a report about the
> results. An initial mass rebuild report was just sent to the
> fedora-mingw mailing list, but if you guys here are interested in it as
> well I can also forward it to this list in the future.

Thanks!

> The report can be found at
> http://lists.fedoraproject.org/pipermail/mingw/2012-November/005884.html

I can see Wine Gecko build failure is due to missing Wine during
compilation. Wine is needed for creating the MSI file in the final stage
of compilation.

Cheers,
Jacek

--
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_d2d_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public