2013/9/14 Jon:
On Sat, Sep 14, 2013 at 9:44 AM, Ruben Van Boxem
I think you guys are missing the main problem: the fact that for the last
half year, trunk was necessary to build the latest GCC version. I'm
confident the whole trunk stability question will descend into only murmurs
if a stable
On 9/16/2013 19:17, Earnie Boyd wrote:
IMO, trunk is a stable branch that all other branches evolve from.
You create a working branch named for the next release that all work
is done to and is unstable up until the call for testing. After the
call for testing only bug fixes for that release
On 9/16/2013 4:38 AM, JonY wrote:
On 9/16/2013 19:17, Earnie Boyd wrote:
IMO, trunk is a stable branch that all other branches evolve from.
You create a working branch named for the next release that all work
is done to and is unstable up until the call for testing. After the
call for
Hi,
On Sat, Sep 14, 2013, Kai Tietz wrote:
2013/9/14 JonY jo...@users.sourceforge.net:
Trunk is already the devel branch, /stable/* is for stable users. what
we could do is make a new /testing that constantly have safe and
proven changes merged from /trunk, kind of like debian-testing,
On 9/14/2013 14:03, Kai Tietz wrote:
2013/9/14 JonY jo...@users.sourceforge.net:
On 9/14/2013 02:45, Ozkan Sezer wrote:
On 9/13/13, Kai Tietz wrote:
Well, I consider, if we might want to define _FORCENAMELESSUNION in
_mingw.h for 3.0, and remove it on our trunk. By this we reduce
fallout
Adrien Nader schreef op za 14-09-2013 om 08:13 [+0200]:
I've already mentioned that; I really prefer to have tarballs and
releases, even if they are preview or alpha.
Currently everyone uses a different CRT and it's almost impossible to
remember the differences between them.
PS: I prefer
On 9/14/2013 19:11, Erik van Pienbroek wrote:
Adrien Nader schreef op za 14-09-2013 om 08:13 [+0200]:
I've already mentioned that; I really prefer to have tarballs and
releases, even if they are preview or alpha.
Currently everyone uses a different CRT and it's almost impossible to
remember
JonY schreef op za 14-09-2013 om 19:24 [+0800]:
Daily automated tarballs already done by buildbot. Probably need to add
something like svnversion to generate release revision info in a special
header.
I personally think daily releases are a bit too much bleeding edge. Of
course they're useful
On 9/14/2013 19:49, Erik van Pienbroek wrote:
JonY schreef op za 14-09-2013 om 19:24 [+0800]:
Daily automated tarballs already done by buildbot. Probably need to add
something like svnversion to generate release revision info in a special
header.
I personally think daily releases are a bit
Op 14-sep.-2013 13:50 schreef Erik van Pienbroek e...@vanpienbroek.nl
het volgende:
JonY schreef op za 14-09-2013 om 19:24 [+0800]:
Daily automated tarballs already done by buildbot. Probably need to add
something like svnversion to generate release revision info in a special
header.
I
JonY, just to let you know that your emails come as an attachment in not in
the body of the email.
Sorry :)
-Original Message-
From: JonY
Sent: Friday, September 13, 2013 9:39 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling
On Sat, Sep 14, 2013 at 9:44 AM, Ruben Van Boxem
vanboxem.ru...@gmail.comwrote:
Op 14-sep.-2013 13:50 schreef Erik van Pienbroek e...@vanpienbroek.nl
het volgende:
JonY schreef op za 14-09-2013 om 19:24 [+0800]:
Daily automated tarballs already done by buildbot. Probably need to add
On 9/14/2013 21:46, Incongruous wrote:
JonY, just to let you know that your emails come as an attachment in not in
the body of the email.
Sorry :)
Use a client that supports PGP/MIME, something other than Outlook express.
signature.asc
Description: OpenPGP digital signature
-Original Message-
From: Kai Tietz [mailto:ktiet...@googlemail.com]
Sent: Friday, September 13, 2013 11:25 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
[...]
The idea to use an svn-hook for this, is pretty
On 9/13/13, Kai Tietz ktiet...@googlemail.com wrote:
Well, I consider, if we might want to define _FORCENAMELESSUNION in
_mingw.h for 3.0, and remove it on our trunk. By this we reduce
fallout right now, provide a version check later on for changed
behavior.
I don't know the specifics about
On 09/10/13 20:35, Jacek Caban wrote:
On 9/10/13 8:25 PM, Erik van Pienbroek wrote:
wine-gecko:
---
../../widget/windows/JumpListBuilder.o: In function
`ZN7mozilla6widget15JumpListBuilderC2Ev':
JonY schreef op di 10-09-2013 om 06:25 [+0800]:
On 9/10/2013 04:48, Erik van Pienbroek wrote:
JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
On 9/9/2013 19:35, Erik van Pienbroek wrote:
wine-mono-0.0.8-3
Build logs:
On 9/10/13 8:25 PM, Erik van Pienbroek wrote:
wine-gecko:
---
../../widget/windows/JumpListBuilder.o: In function
`ZN7mozilla6widget15JumpListBuilderC2Ev':
/builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/widget/windows/JumpListBuilder.cpp:54:
undefined reference to
JonY schreef op vr 06-09-2013 om 18:43 [+0800]:
Hello all,
We will be releasing v3 from trunk soon. Testers, please check with the
latest trunk version if any of the changes break your applications!
Here are the initial results of a test mass rebuild which was done
against r6233.
The
JonY jo...@users.sourceforge.net writes:
We will be releasing v3 from trunk soon. Testers, please check with the
latest trunk version if any of the changes break your applications!
This critical pessimization affecting C++ is still unresolved:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892
On 9/9/2013 19:35, Erik van Pienbroek wrote:
JonY schreef op vr 06-09-2013 om 18:43 [+0800]:
Hello all,
We will be releasing v3 from trunk soon. Testers, please check with the
latest trunk version if any of the changes break your applications!
Here are the initial results of a test
Why? A fix for this problem was already applied upstream. See ChangeLog
2013-07-08 Kai Tietz
PR target/56892
* config/i386/i386.c (TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P): Define as
hook_bool_const_tree_true.
Regards,
Kai
JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
On 9/9/2013 19:35, Erik van Pienbroek wrote:
wine-mono-0.0.8-3
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-mono-0.0.8-3
I just tried to rebuild this one against the latest svn (r6258) and it
still
On 9/10/2013 04:48, Erik van Pienbroek wrote:
JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
On 9/9/2013 19:35, Erik van Pienbroek wrote:
wine-mono-0.0.8-3
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-mono-0.0.8-3
I just tried to rebuild this one
On 07/09/2013, at 3:25 AM, NightStrike nightstr...@gmail.com wrote:
On Fri, Sep 6, 2013 at 11:25 AM, Erik van Pienbroek
Before I kick off another test mass rebuild I would like to know whether
there are still any winpthreads changes pending. Previous test mass
rebuilds have shown that
On 9/8/2013 10:48, Tony Theodore wrote:
On 07/09/2013, at 3:25 AM, NightStrike wrote:
On Fri, Sep 6, 2013 at 11:25 AM, Erik van Pienbroek
Before I kick off another test mass rebuild I would like to know whether
there are still any winpthreads changes pending. Previous test mass
rebuilds
On 08/09/2013, at 12:48 PM, Tony Theodore tony.theod...@gmail.com wrote:
On 07/09/2013, at 3:25 AM, NightStrike nightstr...@gmail.com wrote:
I'm at least trying to get the winpthreads build fixes in that you asked for
On r6232, I'm seeing these build errors in winpthreads itself:
2013/9/6 JonY:
Hello all,
We will be releasing v3 from trunk soon. Testers, please check with the
latest trunk version if any of the changes break your applications!
Some of the new changes since v2 include:
* Improved floating point math performance
* Improved MSVC compiler intrinsics
JonY schreef op vr 06-09-2013 om 18:43 [+0800]:
We will be releasing v3 from trunk soon. Testers, please check with the
latest trunk version if any of the changes break your applications!
Hi Jon and other mingw-w64 devs,
It's great to hear that v3 will be released any day now!
Before I kick
29 matches
Mail list logo