Re: [Mingw-w64-public] Mass rebuild report for January 30 2015
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
Is this with the patch I posted to the mailing list ?
On Fri, Jan 30, 2015 at 12:10 AM, Erik van Pienbroek
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
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
> > 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 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
Re: [Mingw-w64-public] Mass rebuild report for January 30 2015
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
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
--
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
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
> > 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 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
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
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
Re: [Mingw-w64-public] Mass rebuild report for January 30 2015
> > 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 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
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
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
> > 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 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
