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
===
Mass rebuild script for the Fedora MinGW packages written and
maintained by Erik van Pienbroek (epien...@fedoraproject.org)
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own
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
won'
tell
whether additional linker 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 wit
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
these commits also be backported to the v4.x branch?
In Fedora we've manually backported these for now.
Regards,
Erik van Pienbroek
--
___
Mingw-w64-public mailing lis
eqt 5.5.0
5f5e2c1 - activscp: Remove duplicate defines.
Regards,
Erik van Pienbroek
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists
need to use
version 4.0.1 or higher. Additionally you also need 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
-
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
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: epienb
===
The following packages were updated since the previous rebuild:
mingw-crt-4.0-0.2.rc3.fc21
---
* Sat Mar 07 2015 Erik van Pienbroek - 4.0-0.2.rc3
- Update to 4.0rc3
mingw-dbus-glib-0.104-1.fc21
-
* Wed Feb
e in
the CentOS 6 EPEL repository. 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/
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 ah
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 anot
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 de
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-r
--
* Mon Jan 26 2015 Richard Hughes - 1.2.8-1
- Update to latest upstream version
mingw-crt-4.0-0.1.rc1.fc21
---
* Mon Jan 26 2015 Erik van Pienbroek - 4.0-0.1.rc1
- Update to 4.0rc1
mingw-eigen3-3.2.4-1.fc21
--
* Sat Jan 24 2015 Sandro
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 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
#x27;m going to push 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
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
Sandro Mani schreef op za 03-01-2015 om 22:24 [+0100]:
> >> mingw-poppler-0.28.1-1
> >>** Package failed to build while it succeeded during the previous mass
> >> rebuild **
> >>Package owner: smani
> >>Time to build: 2 minutes, 25 seconds
> >>Build logs:
> >> http://build1.vanpie
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:
---
* Mon Dec 29 2014 Erik van Pienbroek -
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-qt5-qtwebkit 5.4
mingw-atk-2.15.3-1.fc21
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 worka
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
but my guess is this is not the right fix as I think wine-gecko should
set _WIN32_WINNT 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 ca
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
> Num
Richard W.M. Jones - 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 -
3.1.999-0.12.trunk.gitec1ff7.20140730
- Update to 20140730 snapshot
pback:
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
Date: Tue, 29 Jul 2014 23:51:43 +0200
Subject: [PATCH] Use correct initializer for in6addr_loopbac
/Packaging:MinGW and put it up
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
===
The following packages were updated since the previous rebuild:
mingw-binutils-2.24-2.fc21
---
* Fri May 30 2014 Erik van Pienbroek - 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
Date: Thu, 29 May 2014 15
SourceForge id: epienbro
[X] Yes, move to git
[ ] No, continue with SVN
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements fo
Sailer - 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 -
4.9.0-0.1.svn.20140330.r208948
- Update to gcc 4.9 20140330 snapshot (rev 208948)
mingw-glibmm24-2.39.92-1.fc21
* Sun Mar 30 2014 Erik van Pienbroek -
3.1.999-0.8.trunk.r6559.20140330
- Update to r6559 (20140330 snapshot)
- Fixes Windows XP compatibility issue in mingw-glib-networking
and mingw-sigar (missing strerror_s symbol)
* Mon Feb 24 2014 Erik van Pienbroek -
3.1.999
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?
> >
>
>
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
Date: Fri, 28 Mar 2014 15:14:25 +0
0-0.9.svn2215.20130517.fc21
---
* Tue Feb 04 2014 Erik van Pienbroek -
0-0.9.svn2215.20130517
- Automatically LoadLibrary("d3dcompiler_43.dll") when no other D3D compiler is
already loaded yet. Fixes RHBZ #1057983
- Make sure the libraries
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-qtdecl
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 :
> > Hey,
>
Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek
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/msvcr
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 :
&g
The attached patches 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 P
.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 - 2.11.3
following packages FAILED to rebuild:
===
The following packages were updated since the previous rebuild:
mingw-atk-2.11.2-1.fc19
* Wed Nov 20 2013 Erik van Pienbroek - 2.11.2-1
- Update to 2.11.2
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 jon_y, is 3.0.1 already out? I see that
you tagged i
Ruben Van Boxem schreef op vr 20-09-2013 om 09:14 [+0200]:
> The next question is why on earth these aren't upstreamed yet?
Well, the first patch is already applied upstream and will be part of
gcc 4.8.2. The other patch was put up for review a long time ago, but
isn't reviewed/accepted yet:
http:
JonY schreef op vr 20-09-2013 om 06:24 [+0800]:
> Hi,
>
> Thanks to all contributors, especially to Erik for running build tests,
> v3 is now nearly stable.
>
> The is only 1 known issue left. one lh_mouse has discovered a bug in
> remquol(). He is taking uncomfortably long to fix it, I'm not hap
Jacek Caban schreef op wo 18-09-2013 om 11:52 [+0200]:
> Hi,
>
> Please review the attached patch. It fixes trunk GCC compilation, which
> is something I think should be done before v3 release. We already talked
> about this on IRC and the comment has short explanation, let me know if
> more info
Roland Schwingel schreef op wo 18-09-2013 om 08:16 [+0200]:
> I experienced the same problem for me 2 days ago after updating my
> runtime to current trunk version. I am building tcl/tk 8.6 for using it
> together with insight debugger.
>
> I patched tcl/tk in exactly the same way (prefixing
>
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 S
Eric Blake schreef op di 17-09-2013 om 15:34 [-0600]:
> I've played with these in my rawhide VM (and fixed several other libvirt
> bugs in the meantime, so the time was not wasted :). I was unable to
> reproduce this particular failure, which may mean that the latest
> winpthreads has indeed fixed
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
.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 - 2.9.4-1
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"
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 usefu
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
Koehne Kai schreef op vr 13-09-2013 om 09:21 [+]:
> > The above toolchains work just fine with the patches ... However, with the
> >
> > http://sourceforge.net/projects/mingw-
> > w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-
> > builds/4.8.1/threads-win32/dwarf/x32-4.8.1
Kai Tietz schreef op vr 13-09-2013 om 11:24 [+0200]:
> HI,
>
> we had in the past already the idea to add svn-revision-number to
> identify version proper. See for this in the mingw-w64-crt/ folder
> the header revstamp.h (a side-note ... actual the place should be
> IMHO instead the mingw-w64-i
JonY schreef op ma 09-09-2013 om 20:32 [+0800]:
> > mingw-tk-8.5.13-3
> > Build logs:
> > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-tk-8.5.13-3
> >
>
> tkWinSend.c:758:9: error: 'VARIANT' has no member named 'vt'
> vCmd.vt = VT_BSTR;
>
> Kai, does oaidl.h nee
With r6277 the wine-gecko and wine-mono failures are resolved.
As mentioned earlier the qt5-qtbase build failure was already resolved by
patching qt5-qtbase.
The qt5-qtsystems issue turned out to be caused by a local patch
we were carrying in qt5-qtbase because of compatibility issues with DBus.
Koehne Kai schreef op do 12-09-2013 om 06:51 [+]:
> > As there are no macros inside
> > mingw-w64 which identify the svn revision all I could came up with is a
> > '__MINGW64_VERSION_MAJOR < 3' conditional as best possible solution.
>
> So which toolchains / Mingw-w64 versions would still bre
Erik van Pienbroek schreef op di 10-09-2013 om 20:25 [+0200]:
> qt5-qtbase:
> ---
>
> /builddir/build/BUILD/qtbase-opensource-src-5.1.1/src/plugins/platforms/windows/qwindowsdialoghelpers.cpp:236:8:
> error: redefinition of 'struct IEnumShellItems'
> DECLAR
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!
I've done another test run against r6259. The amount of failures is
reduced now, but we're
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:
> &
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
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 fo
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
Kai Tietz schreef op do 29-08-2013 om 22:15 [+0200]:
> 2013/8/29 Erik van Pienbroek :
> > Alexey Pavlov schreef op do 29-08-2013 om 23:20 [+0400]:
> >> After fixing tis issue I have issue described here:
> >> https://bugreports.qt-project.org/browse/QTBUG-33225
>
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
> >
Alexey Pavlov schreef op do 29-08-2013 om 23:20 [+0400]:
>
>
>
> 2013/8/29 Erik van Pienbroek
> > mingw-qt5-qtbase-5.1.0-5
> > ** Package failed to build while it succeeded during
> the previous mass rebuild **
> &
LRN schreef op do 29-08-2013 om 22:49 [+0400]:
> On 29.08.2013 21:38, Erik van Pienbroek wrote:
> >> mingw-gstreamer-0.10.36-4
> >>** Package failed to build while it succeeded during the previous mass
> >> rebuild **
> >>Package owner: pfor
>
> mingw-gstreamer-0.10.36-4
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: pfor
> Time to build: 2 minutes, 44 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130829/mingw-gstreamer-0.10.3
mingw-boost-1.54.0-1.fc19
--
* Tue Jul 30 2013 Thomas Sailer - 1.54.0-1
- update to 1.54.0
mingw-cairo-1.12.14-5.fc19
---
* Sun Aug 04 2013 Erik van Pienbroek - 1.12.14-5
- Fix assertion failure when using the latest gtk3 (RHBZ #991829, FD BZ #
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 fai
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= __attr
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
revent this from happening? It is currently
causing issues for us with wine/wine-gecko.
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a fre
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
ss this issue with Qt5 (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=9950
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
===
The following packages were updated since the previous rebuild:
mingw-boost-1.53.0-2.fc19
--
* Sat Jul 20 2013 Erik van Pienbroek - 1.53.0-2
- Fix the build when the native libicu-devel is installed
- Fix FTBFS on recent mingw
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
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
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 inf
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 provi
n't enough
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
dded workarounds
for mingw-specific 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
.dll dependency 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
Date: Thu,
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 chan
t Jul 13 2013 Erik van Pienbroek - 1.2.12-9
- Rebuild against libpng 1.6
mingw-atk-2.9.3-1.fc19
---
* Sat Jul 13 2013 Erik van Pienbroek - 2.9.3-1
- Update to 2.9.3
mingw-cairo-1.12.14-3.fc19
---
* Sat Jul 13 2013 Erik van Pienbroek - 1.12.14-3
- Re
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.
>
ope
__cpuid(info, 1);
^
make[2]: *** [.obj/release-static/qsimd.o] Error 1
So far this looks like a x86_64-w64-mingw32 only regression. The
i686-w64-mingw32 build completes fine.
Full build logs can b
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 tr
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 fro
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 l
.21-1
===
The following packages were updated since the previous rebuild:
mingw-angleproject-0-0.6.svn2215.20130517.fc19
---
* Sat May 18 2013 Erik van Pienbroek -
0-0.6.svn2215.20130517
- Export various sy
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
Kai Tietz schreef op ma 10-06-2013 om 21:49 [+0200]:
> 2013/6/10 Erik van Pienbroek :
> > 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 pa
1 - 100 of 150 matches
Mail list logo
