Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-02-02 Thread Jacek Caban 
On 02/01/15 20:27, Martell Malone wrote:

 OK, will go ahead with v4.0.0 shortly if there are no objections.

 I'm trying to get d3d11 idl additions into wine atm which jacek will
 pull into mingw-w64.
 VLC needs this for the new dx11-vout.
 Would it be possible to hold off a day or two for this ?

If it's holding v4, then we should probably just commit it and not wait
for Wine. Please commit the patch, but make sure it lands on Wine later,
because otherwise it would disappear after the next sync to Wine.

Thanks,
Jacek
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-02-02 Thread Martell Malone 

 If it's holding v4, then we should probably just commit it and not wait
 for Wine. Please commit the patch, but make sure it lands on Wine later,
 because otherwise it would disappear after the next sync to Wine.


Okay I'll submit them shortly for review :)

On Mon, Feb 2, 2015 at 10:19 AM, Jacek Caban ja...@codeweavers.com wrote:

  On 02/01/15 20:27, Martell Malone wrote:

  OK, will go ahead with v4.0.0 shortly if there are no objections.

 I'm trying to get d3d11 idl additions into wine atm which jacek will pull
 into mingw-w64.
  VLC needs this for the new dx11-vout.
  Would it be possible to hold off a day or two for this ?


 If it's holding v4, then we should probably just commit it and not wait
 for Wine. Please commit the patch, but make sure it lands on Wine later,
 because otherwise it would disappear after the next sync to Wine.

 Thanks,
 Jacek


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-02-01 Thread Martell Malone 

 OK, will go ahead with v4.0.0 shortly if there are no objections.

I'm trying to get d3d11 idl additions into wine atm which jacek will pull
into mingw-w64.
VLC needs this for the new dx11-vout.
Would it be possible to hold off a day or two for this ?

On Sat, Jan 31, 2015 at 8:21 PM, Erik van Pienbroek e...@vanpienbroek.nl
wrote:

 JonY schreef op za 31-01-2015 om 20:35 [+0800]:
  On 1/30/2015 08:10, Erik van Pienbroek wrote:
  
   All in all I see no blocking issues in mingw-w64 v4.0rc1.
 
  OK, will go ahead with v4.0.0 shortly if there are no objections.

 Is there still interest in doing another test mass rebuild against the
 latest gcc 5 snapshot before releasing mingw-w64 v4.0?



 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-02-01 Thread JonY 
On 2/2/2015 03:27, Martell Malone wrote:

 OK, will go ahead with v4.0.0 shortly if there are no objections.
 
 I'm trying to get d3d11 idl additions into wine atm which jacek will pull
 into mingw-w64.
 VLC needs this for the new dx11-vout.
 Would it be possible to hold off a day or two for this ?

OK.




0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-31 Thread JonY 
On 1/30/2015 08:10, Erik van Pienbroek wrote:
 
 All in all I see no blocking issues in mingw-w64 v4.0rc1.

OK, will go ahead with v4.0.0 shortly if there are no objections.




0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-30 Thread Martell Malone 

 How about the attached patch? It ensures that _POSIX_THREAD_SAFE_FUNCTIONS
 is defined if we declare *_r functions. This conforms POSIX better and you
 may simply detect those functions in the code using this macro. You said on
 IRC that all those changes are needed because VLC maintainer wants
 mingw-w64 to be POSIX compatible, would that make him happy?


Unfortunately No. localtime_r and gmtime_r are discovered with
AC_REPLACE_FUNCS in autotools
http://git.videolan.org/?p=vlc.git;a=blob;f=configure.ac;h=2704b28cfab8aa6e143a28e09b022dfdbcda10b2;hb=HEAD#l560

I submitted this patch but it was rejected because he said that localtime_r
and gmtime_r should not be inline as that breaks the spec so he won't
accept any kind of work around and that we should comply with the spec.
He said that is is bad enough that we have done this for asprintf and
vasprintf but they aren't part of the spec which is why he allows a
specific check for them. Essentially the only way to fix it is to use
functions.



On Fri, Jan 30, 2015 at 10:20 AM, Jacek Caban ja...@codeweavers.com wrote:

  On 01/30/15 06:00, Martell Malone wrote:

  Correct

 Seems like the patch works as I intended :)

  I will do a patch to turn them back to functions without inline and
 hopefully this puts all the issues to rest :)


 This will bring back previous problems again. I don't see how using
 _POSIX_C_SOURCE would change it. Also, you still have an issue about
 time32_t vs time64_t.

 How about the attached patch? It ensures that _POSIX_THREAD_SAFE_FUNCTIONS
 is defined if we declare *_r functions. This conforms POSIX better and you
 may simply detect those functions in the code using this macro. You said on
 IRC that all those changes are needed because VLC maintainer wants
 mingw-w64 to be POSIX compatible, would that make him happy?

 Cheers,
 Jacek


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




0009-Fix-localtime_r-and-gmtime_r-inline-issues.patch
Description: Binary data
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-30 Thread Jacek Caban 
On 01/30/15 06:00, Martell Malone wrote:

 Correct

 Seems like the patch works as I intended :)

 I will do a patch to turn them back to functions without inline and
 hopefully this puts all the issues to rest :)

This will bring back previous problems again. I don't see how using
_POSIX_C_SOURCE would change it. Also, you still have an issue about
time32_t vs time64_t.

How about the attached patch? It ensures that
_POSIX_THREAD_SAFE_FUNCTIONS is defined if we declare *_r functions.
This conforms POSIX better and you may simply detect those functions in
the code using this macro. You said on IRC that all those changes are
needed because VLC maintainer wants mingw-w64 to be POSIX compatible,
would that make him happy?

Cheers,
Jacek
commit d466b776a7acbe561f17089e7877b53a585d03ce
Author: Jacek Caban ja...@codeweavers.com
Date:   Fri Jan 30 11:16:50 2015 +0100

time.h: Ensure that _POSIX_THREAD_SAFE_FUNCTIONS is defined if we declare 
*_r functions.

diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index b551a27..4ff1b14 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -261,7 +261,11 @@ struct timezone {
 
 #pragma pack(pop)
 
-#if defined(_POSIX) || defined(_POSIX_THREAD_SAFE_FUNCTIONS)
+#if defined(_POSIX_C_SOURCE)  !defined(_POSIX_THREAD_SAFE_FUNCTIONS)
+#define _POSIX_THREAD_SAFE_FUNCTIONS 200112L
+#endif
+
+#ifdef _POSIX_THREAD_SAFE_FUNCTIONS
 __forceinline struct tm *__cdecl localtime_r(const time_t *_Time, struct tm 
*_Tm) {
   return localtime_s(_Tm, _Time) ? NULL : _Tm;
 }
@@ -274,7 +278,7 @@ __forceinline char *__cdecl ctime_r(const time_t *_Time, 
char *_Str) {
 __forceinline char *__cdecl asctime_r(const struct tm *_Tm, char * _Str) {
   return asctime_s(_Str, 0x7fff, _Tm) ? NULL : _Str;
 }
-#endif /* _POSIX */
+#endif
 
 /* Adding timespec definition.  */
 #include sys/timeb.h
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-30 Thread Jacek Caban 
Hi Erik,

On 01/30/15 01:10, Erik van Pienbroek wrote:
 Erik van Pienbroek schreef op vr 30-01-2015 om 00:54 [+0100]:
 mingw-qt5-qtjsbackend-5.1.1-5
  ** Package failed to build while it succeeded during the previous mass 
 rebuild **
  Package owner: epienbro
  Time to build: 2 minutes, 12 seconds
  Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-qt5-qtjsbackend-5.1.1-5
 This is a new one and might be triggered by the localtime_s patch:

 /builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:
  In function 'int localtime_s(tm*, const time_t*)':
 /builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:93:5:
  error: redefinition of 'int localtime_s(tm*, const time_t*)'
  int localtime_s(tm* out_tm, const time_t* time) {

 My first guess would be that this needs to be fixed in qtjsbackend as it
 shouldn't try to re-implement toolchain features.

Yeah, that sounds right. We previously declared those only if
MINGW_HAS_SECURE_API, now we do that unconditionally, so I guess the bug
was always there, but wasn't found because it was built without
MINGW_HAS_SECURE_API

 mingw-SDL2-2.0.3-4
  ** Package failed to build while it succeeded during the previous mass 
 rebuild **
  Package owner: maci
  Time to build: 1 minute, 24 seconds
  Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-SDL2-2.0.3-4

 This also sounds like one which needs to be resolved in SDL2 itself:

 ../src/render/direct3d11/SDL_render_d3d11.c:94:5: error: unknown type
 name 'IDXGIFactory2'
  IDXGIFactory2 *dxgiFactory;
  ^
 ../src/render/direct3d11/SDL_render_d3d11.c:96:5: error: unknown type
 name 'ID3D11Device1'
  ID3D11Device1 *d3dDevice;
  ^
 ../src/render/direct3d11/SDL_render_d3d11.c:136:19: error: static
 declaration of 'IID_IDXGIDevice1' follows non-static declaration
  static const GUID IID_IDXGIDevice1 = { 0x77db970f, 0x6276, 0x48ba,
 { 0xba, 0x28, 0x07, 0x01, 0x43, 0xb4, 0x39, 0x2c } };

Missing IDXGIFactory2 and ID3D11Device1 should be fixed in mingw-64 (and
Wine), duplicated IID_IDXGIDevice1 declaration seems like SDL2's fault.

Jacek

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-29 Thread Erik van Pienbroek 
Erik van Pienbroek schreef op vr 30-01-2015 om 00:54 [+0100]:
 The following packages FAILED to rebuild:
 
 mingw-clucene-2.3.3.4-10
   Package owner: greghellings
   Time to build: 2 minutes,
   Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-clucene-2.3.3.4-10

Also failed in previous test mass rebuild with:
/usr/i686-w64-mingw32/sys-root/mingw/include/process.h:31:29: note:
previous declaration 'uintptr_t _beginthread(void
(__attribute__((__cdecl__)) *)(void*), unsigned int, void*)'
   _CRTIMP uintptr_t __cdecl _beginthread(void (__cdecl *_StartAddress)
(void *),unsigned _StackSize,void *_ArgList);

Needs to be resolved in CLucene upstream


 mingw-qt-4.8.6-6
   Package owner: sailer
   Time to build: 22 minutes, 22 seconds
   Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-qt-4.8.6-6

Also failed in previous test mass rebuild with:
/usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ce3):
 undefined reference to `GetExtendedTcpTable@24'
/usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ea8):
 undefined reference to `GetExtendedTcpTable@24'

This is probably a Fedora packaging issue


 mingw-qt5-qtjsbackend-5.1.1-5
   ** Package failed to build while it succeeded during the previous mass 
 rebuild **
   Package owner: epienbro
   Time to build: 2 minutes, 12 seconds
   Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-qt5-qtjsbackend-5.1.1-5

This is a new one and might be triggered by the localtime_s patch:

/builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:
 In function 'int localtime_s(tm*, const time_t*)':
/builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:93:5:
 error: redefinition of 'int localtime_s(tm*, const time_t*)'
 int localtime_s(tm* out_tm, const time_t* time) {

My first guess would be that this needs to be fixed in qtjsbackend as it
shouldn't try to re-implement toolchain features.



 mingw-SDL2-2.0.3-4
   ** Package failed to build while it succeeded during the previous mass 
 rebuild **
   Package owner: maci
   Time to build: 1 minute, 24 seconds
   Build logs: 
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-SDL2-2.0.3-4


This also sounds like one which needs to be resolved in SDL2 itself:

../src/render/direct3d11/SDL_render_d3d11.c:94:5: error: unknown type
name 'IDXGIFactory2'
 IDXGIFactory2 *dxgiFactory;
 ^
../src/render/direct3d11/SDL_render_d3d11.c:96:5: error: unknown type
name 'ID3D11Device1'
 ID3D11Device1 *d3dDevice;
 ^
../src/render/direct3d11/SDL_render_d3d11.c:136:19: error: static
declaration of 'IID_IDXGIDevice1' follows non-static declaration
 static const GUID IID_IDXGIDevice1 = { 0x77db970f, 0x6276, 0x48ba,
{ 0xba, 0x28, 0x07, 0x01, 0x43, 0xb4, 0x39, 0x2c } };



All in all I see no blocking issues in mingw-w64 v4.0rc1.

Regards,

Erik van Pienbroek



--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-29 Thread Martell Malone 
Is this with the patch I posted to the mailing list ?

On Fri, Jan 30, 2015 at 12:10 AM, Erik van Pienbroek e...@vanpienbroek.nl
wrote:

 Erik van Pienbroek schreef op vr 30-01-2015 om 00:54 [+0100]:
  The following packages FAILED to rebuild:
 
  mingw-clucene-2.3.3.4-10
Package owner: greghellings
Time to build: 2 minutes,
Build logs:
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-clucene-2.3.3.4-10

 Also failed in previous test mass rebuild with:
 /usr/i686-w64-mingw32/sys-root/mingw/include/process.h:31:29: note:
 previous declaration 'uintptr_t _beginthread(void
 (__attribute__((__cdecl__)) *)(void*), unsigned int, void*)'
_CRTIMP uintptr_t __cdecl _beginthread(void (__cdecl *_StartAddress)
 (void *),unsigned _StackSize,void *_ArgList);

 Needs to be resolved in CLucene upstream


  mingw-qt-4.8.6-6
Package owner: sailer
Time to build: 22 minutes, 22 seconds
Build logs:
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-qt-4.8.6-6

 Also failed in previous test mass rebuild with:
 /usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ce3):
 undefined reference to `GetExtendedTcpTable@24'
 /usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ea8):
 undefined reference to `GetExtendedTcpTable@24'

 This is probably a Fedora packaging issue


  mingw-qt5-qtjsbackend-5.1.1-5
** Package failed to build while it succeeded during the previous
 mass rebuild **
Package owner: epienbro
Time to build: 2 minutes, 12 seconds
Build logs:
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-qt5-qtjsbackend-5.1.1-5

 This is a new one and might be triggered by the localtime_s patch:

 /builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:
 In function 'int localtime_s(tm*, const time_t*)':
 /builddir/build/BUILD/qtjsbackend-opensource-src-5.1.1/src/3rdparty/v8/src/platform-win32.cc:93:5:
 error: redefinition of 'int localtime_s(tm*, const time_t*)'
  int localtime_s(tm* out_tm, const time_t* time) {

 My first guess would be that this needs to be fixed in qtjsbackend as it
 shouldn't try to re-implement toolchain features.



  mingw-SDL2-2.0.3-4
** Package failed to build while it succeeded during the previous
 mass rebuild **
Package owner: maci
Time to build: 1 minute, 24 seconds
Build logs:
 http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150130/mingw-SDL2-2.0.3-4


 This also sounds like one which needs to be resolved in SDL2 itself:

 ../src/render/direct3d11/SDL_render_d3d11.c:94:5: error: unknown type
 name 'IDXGIFactory2'
  IDXGIFactory2 *dxgiFactory;
  ^
 ../src/render/direct3d11/SDL_render_d3d11.c:96:5: error: unknown type
 name 'ID3D11Device1'
  ID3D11Device1 *d3dDevice;
  ^
 ../src/render/direct3d11/SDL_render_d3d11.c:136:19: error: static
 declaration of 'IID_IDXGIDevice1' follows non-static declaration
  static const GUID IID_IDXGIDevice1 = { 0x77db970f, 0x6276, 0x48ba,
 { 0xba, 0x28, 0x07, 0x01, 0x43, 0xb4, 0x39, 0x2c } };



 All in all I see no blocking issues in mingw-w64 v4.0rc1.

 Regards,

 Erik van Pienbroek




 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-29 Thread Erik van Pienbroek 
Martell Malone schreef op vr 30-01-2015 om 00:32 [+]:
 Is this with the patch I posted to the mailing list ?

Correct


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for January 30 2015

2015-01-29 Thread Martell Malone 

 Correct

Seems like the patch works as I intended :)

I will do a patch to turn them back to functions without inline and
hopefully this puts all the issues to rest :)

On Fri, Jan 30, 2015 at 12:57 AM, Erik van Pienbroek e...@vanpienbroek.nl
wrote:

  Martell Malone schreef op vr 30-01-2015 om 00:32 [+]:

 Is this with the patch I posted to the mailing list ?

 Correct




 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public