Erik van Pienbroek schreef op wo 11-05-2016 om 19:35 [+0200]:
> The following packages FAILED to rebuild:
>
> mingw-clucene-2.3.3.4-14
> Package owner: greghellings
> Time to build: 1 minute, 16 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-m
julien.darthe...@laposte.net schreef op di 12-04-2016 om 12:08 [+0200]:
> http://www.qtcentre.org/threads/38060-How-to-fix-this-error-undefined
> -reference-to-IID_IMultiLanguage
>
> You seem to need - lmlang linker option.
Unfortunately there's no mlang import library in mingw-w64 so that
flags are needed for this interface, but
adding -luuid doesn't resolve the issue
Regards,
Erik van Pienbroek
##SELECTION_END##
--
Find and fix application performance issues faster with Applications Manager
Applications
Jacek Caban schreef op ma 08-02-2016 om 13:59 [+0100]:
> Hi,
>
> FWIW, new Wine Gecko has been released lately, which also depends on
> git
> master and I'm not sure how hard backporting required fixes will be.
> I'm
> sure that having a release would make distro's life easier.
>
Hi Jacek,
For
defines.
Regards,
Erik van Pienbroek
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
to apply these two
patches which we are using in Fedora to get SDL2 built:
http://pkgs.fedoraproject.org/cgit/mingw-SDL2.git/tree/SDL2-fix-gcc
-compatibility.patch
http://pkgs.fedoraproject.org/cgit/mingw-SDL2.git/tree/SDL2-prevent
-duplicate-d3d11-declarations.patch
Regards,
Erik van Pienbroek
JonY schreef op zo 15-03-2015 om 09:20 [+0800]:
*** Known Issues ***
SDL2 build is broken due to incomplete DX11 support in mingw-w64 and
some duplicated declarations in SDL2. Disabling the DX11 backend
seems to fix things temporarily.
FYI, I just spent some time investigating this issue
===
The following packages were updated since the previous rebuild:
mingw-crt-4.0-0.2.rc3.fc21
---
* Sat Mar 07 2015 Erik van Pienbroek epien...@fedoraproject.org - 4.0-0.2.rc3
- Update to 4.0rc3
mingw-dbus-glib-0.104-1.fc21
Erik van Pienbroek schreef op zo 08-03-2015 om 17:43 [+0100]:
The following packages FAILED to rebuild:
mingw-angleproject-0-0.11.git.30d6c2.20141113
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: epienbro
Time to build
. It's as easy as 'yum install mingw32-
gcc' to get the mingw-w64 compiler installed for the win32 target. For
more information see https://fedoraproject.org/wiki/MinGW/Tutorial
Regards,
Erik van Pienbroek
--
Download
Erik van Pienbroek schreef op za 31-01-2015 om 21:21 [+0100]:
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
Martell Malone schreef op do 29-01-2015 om 15:23 [+]:
This change makes sense. Right now Eric is checking this
change on
Fedora. So we should wait for his results.
Yes but I think he should also build on rc1 without the patch to make
sure that if there is a
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
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
--
* Mon Jan 26 2015 Richard Hughes rich...@hughsie.com - 1.2.8-1
- Update to latest upstream version
mingw-crt-4.0-0.1.rc1.fc21
---
* Mon Jan 26 2015 Erik van Pienbroek epien...@fedoraproject.org - 4.0-0.1.rc1
- Update to 4.0rc1
mingw-eigen3-3.2.4-1.fc21
it to Fedora rawhide and
Fedora 21 testing. Afterwards another iteration of the test mass
rebuild can be performed.
Regards,
Erik van Pienbroek
--
Dive into the World of Parallel Programming. The Go Parallel Website
Erik van Pienbroek schreef op ma 26-01-2015 om 21:29 [+0100]:
JonY schreef op zo 25-01-2015 om 09:36 [+0800]:
Hello all,
v4.x has been branched, and the first release candidate has been
released on sourceforge. If all goes well, v4.0.0 will be released
by next week. Testers, please
Jacek Caban schreef op ma 05-01-2015 om 14:05 [+0100]:
On 01/04/15 12:49, Jacek Caban wrote:
Maybe I missed some better options for us. None of above is perfect and
I'm not sure what we should do about it. Solution 2. seems the least
problematic.
Looking deeper at this, current
---
* Mon Dec 29 2014 Erik van Pienbroek epien...@fedoraproject.org -
0-0.11.git.30d6c2.20141113
- Update to 20141113 snapshot (git revision 30d6c2)
- Include all patches which were used by the Qt5 fork
- Reverted some recent commits as they break mingw
Erik van Pienbroek schreef op za 03-01-2015 om 20:43 [+0100]:
The following packages FAILED to rebuild:
mingw-cairo-1.14.0-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: rjones
Time to build: 1 minute, 32 seconds
Jacek Caban schreef op vr 02-01-2015 om 10:46 [+0100]:
On 01/01/15 18:30, Erik van Pienbroek wrote:
Apparently wine-gecko fails to build when these symbols are only
available with _WIN32_WINNT = 0x0600. @Jacek: could this be a
wine-gecko bug? I've workaround'ed this issue in Fedora 20 using
Adrien Nader schreef op ma 15-12-2014 om 22:09 [+0100]:
Maybe smaller and more frequent releases? It seemed to me that a release
every 6-month or so (very roughly) would fit. I'm not arguing for strict
time-based release but rather looking at the tree something like 6
months after the last
to 0x0600 while compiling the file
hal/windows/WindowsBattery.cpp.
Would it be possible to backport all the commits mentioned in this mail
to the mingw-w64 v3.x branch and release a mingw-w64 v3.4.0 soon so
others can benefit from these changes as well?
Regards,
Erik van Pienbroek
Fedora MinGW SIG
* Wed Jun 11 2014 Richard W.M. Jones rjo...@redhat.com - 201406-1
- Update the database against packages in Fedora 20.
mingw-crt-3.1.999-0.12.trunk.gitec1ff7.20140730.fc21
-
* Wed Jul 30 2014 Erik van Pienbroek epien...@fedoraproject.org
Erik van Pienbroek schreef op zo 03-08-2014 om 14:14 [+0200]:
Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20140803
Total packages: 200
Number of failed packages: 3
Number of succeeded packages: 197
Number of added packages since
:
https://bugzilla.redhat.com/show_bug.cgi?id=1124368
Okay to apply?
Regards,
Erik van Pienbroek
From e6290e7bb7d0a7ddf541dc8243407909d63c139d Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Date: Tue, 29 Jul 2014 23:51:43 +0200
Subject: [PATCH] Use correct initializer
for review using the instructions which can be found at
https://fedoraproject.org/wiki/PackageMaintainers/Join
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
HPCC Systems Open Source Big Data Platform from
===
The following packages were updated since the previous rebuild:
mingw-binutils-2.24-2.fc21
---
* Fri May 30 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.24-2
- Fix FTBFS against gcc 4.9
mingw-cairo-1.12.16-2.fc21
Prevents warnings from showing up when using the
macros IN6ADDR_ANY_INIT or IN6ADDR_LOOPBACK_INIT
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1067426
OK to apply?
From b8e8160da0648fc0406b028a2bff0938d9b9175e Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Date
Sailer t.sai...@alumni.ethz.ch - 3.3.4-1
- update to 3.3.4
mingw-gcc-4.9.0-0.1.svn.20140330.r208948.fc21
--
* Wed Apr 02 2014 Erik van Pienbroek epien...@fedoraproject.org -
4.9.0-0.1.svn.20140330.r208948
- Update to gcc 4.9 20140330 snapshot (rev
Jacek Caban schreef op vr 28-03-2014 om 16:10 [+0100]:
On 03/28/14 15:39, Erik van Pienbroek wrote:
Hi,
Attached patch fixes a compatibility issue with p11-kit and sigar on
Windows XP (missing strerror_s symbol). Okay to commit?
Looks good to me.
Thanks,
Jacek
Committed to trunk
Hi,
Attached patch fixes a compatibility issue with p11-kit and sigar on
Windows XP (missing strerror_s symbol). Okay to commit?
Regards,
Erik van Pienbroek
From aa643f570cd1cb7c515af405fd844aab3c69ab45 Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Date: Fri, 28
Erik van Pienbroek schreef op zo 09-02-2014 om 15:50 [+0100]:
The following packages FAILED to rebuild:
mingw-boost-1.54.0-1
mingw-llvm-3.0-7
mingw-poppler-0.24.5-1
mingw-qpid-cpp-0.14-8
mingw-qt-4.8.5-4
mingw-qt5-qtbase-5.2.1-1
mingw-qt5-qtdeclarative-5.2.1-1
mingw-qt5-qtjsbackend
.svn2215.20130517.fc21
---
* Tue Feb 04 2014 Erik van Pienbroek epien...@fedoraproject.org -
0-0.9.svn2215.20130517
- Automatically LoadLibrary(d3dcompiler_43.dll) when no other D3D compiler is
already loaded yet. Fixes RHBZ #1057983
- Make sure
:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Date: Sun, 26 Jan 2014 20:15:44 +0100
Subject: [PATCH] Add secapi wrapper for sprintf_s
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/Makefile.in | 45 +++
mingw-w64-crt/lib32
Thanks, committed as r6469
Kai Tietz schreef op zo 26-01-2014 om 20:25 [+0100]:
Hello Erik,
patch is ok for trunk. It might be something for 3.x too. Latter is
JonY's decision.
Thanks,
Kai
2014-01-26 Erik van Pienbroek e...@vanpienbroek.nl:
Hey,
Here's a patch which implements
Committed as r6450 and r6451
Kai Tietz schreef op ma 20-01-2014 om 15:00 [+0100]:
Hallo Eric,
both patches are ok. Please apply to trunk. Jon_y those patches
should be applied to 3.x branch too.
Thanks,
Kai
2014/1/19 Erik van Pienbroek e...@vanpienbroek.nl:
Hi,
One of our
should fix
these.
Regards,
Erik van Pienbroek
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1054481
[2]:
http://svn.nntpgrab.nl/svn/fedora_mingw_testsuite/trunk/testcases/def/secapi/
From ec2ee6e10e3bcdf00c2e93eed427cc8c2b626cac Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien
.vanpienbroek.nl/fedora-mingw-rebuild/20140111/mingw-libgsf-1.14.28-1
===
The following packages were updated since the previous rebuild:
mingw-atk-2.11.3-1.fc19
* Thu Dec 05 2013 Erik van Pienbroek epien
===
The following packages FAILED to rebuild:
none
===
The following packages were updated since the previous rebuild:
mingw-atk-2.11.2-1.fc19
* Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org
Ruben Van Boxem schreef op wo 02-10-2013 om 16:58 [+0200]:
Hi,
I just noticed there is an SVN tag for 3.0.1 but no tarball.
Could one be uploaded please?
Hey Ruben,
Some days ago I also mentioned this on IRC:
sep 30 23:13:12 epienbroekjon_y, is 3.0.1 already out? I see that
you
.vanpienbroek.nl/fedora-mingw-rebuild/20130917/mingw-tk-8.5.13-3
===
The following packages were updated since the previous rebuild:
mingw-atk-2.9.4-1.fc19
---
* Sat Sep 07 2013 Erik van Pienbroek epien
JonY schreef op di 17-09-2013 om 22:54 [+0800]:
So, do we go ahead with the v3 release?
I don't really have a vote in this. The test mass rebuild has shown that
there are only 2 build failures remaining: tk and tcl which both suffer
from the issue mentioned in this thread. Of course it would be
Erik van Pienbroek schreef op di 17-09-2013 om 20:34 [+0200]:
The test mass rebuild has shown that
there are only 2 build failures remaining: tk and tcl which both suffer
from the issue mentioned in this thread.
The package maintainer of the mingw-tcl package in Fedora, Thomas Sailer
has just
Hey all,
The test mass rebuild against r6284 has shown that tcl currently still
fails to build:
i686-w64-mingw32-gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions --param=ssp-buffer-size=4 -O2 -fomit-frame-pointer -Wall
-I../../generic -DTCL_TOMMATH -DMP_PREC=4 -I../../libtommath
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
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
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:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909
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 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
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
Eric Blake schreef op do 29-08-2013 om 14:07 [-0600]:
On 08/29/2013 11:38 AM, Erik van Pienbroek wrote:
This mass rebuild was done using winpthreads instead of the old
pthreads-w32 implementation. In Fedora itself winpthreads isn't
used by default yet, but it will be introduced
Erik van Pienbroek schreef op wo 21-08-2013 om 07:55 [+0200]:
Hi,
The current trunk seems to have some conflicting declarations which
causes various build failures. Here are the failures we discovered with
the test mass rebuild script.
Additionally these two failures were also discovered
Hi,
The current trunk seems to have some conflicting declarations which
causes various build failures. Here are the failures we discovered with
the test mass rebuild script.
===
NSIS:
i686-w64-mingw32-gcc -o build/release/stub_bzip2/Ui.o -c -Os -Wall -xc
-fno-strict-aliasing -DNSISCALL=
LRN schreef op ma 12-08-2013 om 20:13 [+0400]:
On 12.08.2013 20:02, Erik van Pienbroek wrote:
Hey,
We've been observing some odd behavior in gcc 4.8. We've noticed that a
lot of shared libraries for the i686 target now started to depend on
libgcc_s_sjlj-1.dll which didn't happen before
(and was reported to this list [1]). Some
days ago also a GTK3 crash was reported to us Fedora maintainers which
can't be caught with gdb [2].
[1]: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/6739
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=995059
Regards,
Erik van Pienbroek
Kai Tietz schreef op do 08-08-2013 om 15:49 [+0200]:
Hmm, not necessarily a gcc bug. It might be simply that the dll
itself has dependencies to other dll-files.
Try to check by dependency-walker tool, or via the objdump tool, what
other DLL-files might be referenced.
Most likely it is an
===
The following packages were updated since the previous rebuild:
mingw-boost-1.53.0-2.fc19
--
* Sat Jul 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.53.0-2
- Fix the build when the native libicu-devel is installed
Erik van Pienbroek schreef op do 25-07-2013 om 23:14 [+0200]:
mingw-cximage-600-9
Package owner: elmarco
Time to build: 2 minutes, 46 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-cximage-600-9
This one was already a known failure
Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]:
On 07/21/13 23:24, dw wrote:
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR = 3)?
IMO, if the change works with
dw schreef op za 20-07-2013 om 23:48 [-0700]:
So, who decides? If it's me, I'm probably going to wimp out and add the
defs back to avoid the conflict.
I've just forwarded all our information to the Fedora maintainer of the
mingw-boost package - Thomas Sailer - and asked him if he could
Erik van Pienbroek schreef op zo 21-07-2013 om 12:22 [+0200]:
dw schreef op za 20-07-2013 om 23:48 [-0700]:
So, who decides? If it's me, I'm probably going to wimp out and add the
defs back to avoid the conflict.
I've just forwarded all our information to the Fedora maintainer
Erik van Pienbroek schreef op zo 21-07-2013 om 14:49 [+0200]:
So now I think it's up to us to come up with the most proper fix which
we can then try to get upstreamed.
Attached is the patch I came up with to fix the build issue. It is
basically method 2 in dw's original mail.
The header
toolchain bugs we could try to persuade them to drop
or loosen these workarounds.
Regards,
Erik van Pienbroek
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application
and that code patches really are needed..
Regards,
Erik van Pienbroek
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks
to disappear from compiled binaries.
Is this patch the correct solution to fixing this issue or do you think
the real cause is somewhere else?
Regards,
Erik van Pienbroek
From a289e2cf5e9f158b861612ceb047a35a2b523c98 Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Erik van Pienbroek schreef op ma 15-07-2013 om 23:31 [+0200]:
Number of failed packages: 16
This iteration of the mass rebuild has been a bad one. Next to the
already known failures (caused by winpthreads) several new ones have
started to pop up related to the recent mingw-w64 intrinsic changes
regression. The
i686-w64-mingw32 build completes fine.
Full build logs can be found at
http://koji.fedoraproject.org/koji/taskinfo?taskID=5605337
Have you got any idea what might be going wrong here?
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op zo 14-07-2013 om 13:25 [+0200]:
Hi,
My apologies for hijacking this thread, but I'm afraid a regression was
introduced by your recent intrin patches. The regression is about the
__cpuid symbol. The qt4 package uses this symbol.
The compilation of qt 4.8.5
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]:
Hi,
During review of one of our Fedora packages we noticed an unexpected
change in behavior in recent mingw-w64 trunk snapshots. We noticed that
several libraries which were built against recent mingw-w64 trunk
snapshots suddenly
===
The following packages were updated since the previous rebuild:
mingw-angleproject-0-0.6.svn2215.20130517.fc19
---
* Sat May 18 2013 Erik van Pienbroek epien...@fedoraproject.org -
0-0.6.svn2215.20130517
JonY schreef op zo 30-06-2013 om 19:29 [+0800]:
On 6/30/2013 18:26, Erik van Pienbroek wrote:
The following packages FAILED to rebuild:
mingw-glew-1.9.0-4
Package owner: smani
Time to build: 3 minutes, 13 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw
Yaakov (Cygwin/X) schreef op zo 30-06-2013 om 10:49 [-0500]:
On 2013-06-30 06:29, JonY wrote:
On 6/30/2013 18:26, Erik van Pienbroek wrote:
The following packages FAILED to rebuild:
mingw-glew-1.9.0-4
Wrong strip called from install -s?
Yes:
http://cygwin-ports.git.sourceforge.net
Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]:
For now I've managed to workaround the regression by partially reverting
r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead
of libkernel32 (as it was before r5713). I'm using this patch now in the
Fedora mingw
Kai Tietz schreef op ma 10-06-2013 om 21:49 [+0200]:
2013/6/10 Erik van Pienbroek e...@vanpienbroek.nl:
Any news on this issue?
I will take a look to this this evening. We will need to remove here
the alias-code to fix that
For now I've managed to workaround the regression by partially
Erik van Pienbroek schreef op za 25-05-2013 om 20:46 [+0200]:
Here's a really minimal testcase which demonstrates the problem:
$ touch foo.c
$ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols
$ i686-w64-mingw32-objdump -p foo.dll
snip
[Ordinal/Name Pointer] Table
also do this in winpthreads/mingw-w64-headers?
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
be the mingw-w64-crt so that each compiled binary can have access
to these symbols.
What are your opinions about this?
Regards,
Erik van Pienbroek
[1]: http://sourceforge.net/mailarchive/message.php?msg_id=30821407
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]:
Hi,
During review of one of our Fedora packages we noticed an unexpected
change in behavior in recent mingw-w64 trunk snapshots. We noticed that
several libraries which were built against recent mingw-w64 trunk
snapshots suddenly
to open the package manager,
search for 'mingw32-gcc' and press the install button).
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
AlienVault Unified Security Management (USM) platform delivers complete
security
-2.0.999-0.23.trunk.20130509.fc19
---
* Thu May 09 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.0.99-0.23.trunk.20130509
- Regenerated 20130509 snapshot
- Dropped upstreamed vsprintf_s patch
* Thu May 09 2013 Erik van Pienbroek epien
Erik van Pienbroek schreef op zo 12-05-2013 om 16:35 [+0200]:
The following packages FAILED to rebuild:
All build failures (except for gtk3) seem to be caused by the
introduction of winpthreads, so we need to resolve these first before
winpthreads can be fully introduced in the Fedora
in the upstream mingw-w64
repo.
The patch doesn't contain an updated Makefile.in as I'm using a
different version of autotools which causes too much other parts to
change as well, so automake need to be run before committing this patch
(I don't have commit rights to the mingw-w64 repo).
Regards,
Erik van
Hi,
The attached patch was contributed to us by Conrad Meyer [1] and adds a
declaration for the function HidD_GetHidGuid [2] to hidsdi.h. Could it
be applied in the mingw-w64 repo?
Regards,
Erik van Pienbroek
Fedora MinGW SIG
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=917400
[2]: http
===
The following packages were updated since the previous rebuild:
mingw-crt-2.0.999-0.20.trunk.20130425.fc19
---
* Thu Apr 25 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.20.trunk.20130425
- Update
JonY schreef op za 27-04-2013 om 20:28 [+0800]:
On 4/27/2013 18:40, Erik van Pienbroek wrote:
Erik van Pienbroek schreef op za 27-04-2013 om 12:30 [+0200]:
The following packages FAILED to rebuild:
mingw-gettext-0.18.2-2
** Package failed to build while it succeeded during
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset
Erik van Pienbroek schreef op wo 17-04-2013 om 12:06 [+0200]:
It might help for your case as well:
https://bugzilla.gnome.org/show_bug.cgi?id=698118
One small addition: the patch in that bug report is based on glib git
master, for one which can be applied to glib 2.36.0 see
http
===
The following packages were updated since the previous rebuild:
mingw-angleproject-0-0.4.svn1561.20121214.fc19
---
* Thu Apr 04 2013 Erik van Pienbroek epien...@fedoraproject.org -
0-0.4.svn1561.20121214
- Added another workaround due to the fact
-w64-headers/include/setupapi.h: WINSETUPAPI WINBOOL WINAPI
SetupUninstallOEMInfW(PCWSTR InfFileName,DWORD Flags,PVOID Reserved);
Can somebody of the mingw-w64 devs indicate whether this is intended?
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op vr 18-01-2013 om 13:11 [+0100]:
Hi,
I just performed a test mass rebuild of all Fedora MinGW packages
against a recent gcc 4.8 snapshot.
During this mass rebuild the following toolchain was used:
* mingw-w64 20130105 trunk snapshot
* binutils 2.23.51.0.5
,
https://bugzilla.redhat.com/896442) which should make automake a bit
less broken. Right now I'm trying to another rebuild attempt against
this latest automake to see if it reduces the number of build failures.
I'll report back once this rebuild attempt is completed.
Regards,
Erik van Pienbroek
Koehne Kai schreef op wo 16-01-2013 om 15:56 [+]:
So it seems that somehow things go wrong in the crash handler. Any idea where
and whether it has been reported before? Especially the Invalid parameter'
warning is somewhat misleading, and sounds like a bug ...
While testing the
Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.16.trunk.20130105
- Update to 20130105 snapshot
mingw-filesystem-97-1.fc19
---
* Sun Dec 16 2012 Erik van Pienbroek epien...@fedoraproject.org - 97-1
- Added support for using the environment variables
pavel schreef op vr 21-12-2012 om 08:46 [+0100]:
When building glib with the x86_64 target, I get the following error at
some point of linking:
CC gspawn-win32.lo
CC gwin32.lo
cd .. /bin/bash ./config.status glib/glib.rc
config.status: creating glib/glib.rc
===
The following packages were updated since the previous rebuild:
mingw-crt-2.0.999-0.15.trunk.20121110.fc19
---
* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.15.trunk.20121110
- Update
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
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
-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
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
1 - 100 of 119 matches
Mail list logo
