sked on that list:
https://admin.fedoraproject.org/mailman/listinfo/mingw
Kind regards,
Erik van Pienbroek
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, app
mingw-w64 packages when I
noticed that the source code tarball at the link you mentioned is
now .tar.gz while it was .tar.bz2 before. Is this change intentional?
Kind regards,
Erik van Pienbroek
--
All the data con
gwex.a(lib64_libmingwex_a-mingw_pformat.o):(.text+0x1e83):
undefined reference to `wcslen'
Building binaries for the i686 target work just fine.
Is it also needed to rebuild gcc with the new crt in place?
Kind regards,
Erik van Pienbroek
---
86 library then it does give some
output:
$
i686-w64-mingw32-nm /usr/i686-w64-mingw32/sys-root/mingw/lib/libmsvcrt.a
| grep wcslen
I __imp__wcslen
T _wcslen
Kind regards,
Erik van Pienbroek
--
RSA(R)
mingw32/sys-root/mingw/lib/../lib/crtend.o
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib64_libmingwex_a-mingw_pformat.o):(.text+0x1e83):
undefined reference to `wcslen'
collect2: ld returned 1 exit status
As you can see t
x86_64 target. The
i686 target works just fine.
If you're interested I can provide you with complete build logs for
binutils, gcc and/or the mingw-w64 crt in private mail.
Kind regards,
Erik van Pienbroek
---
intf DATA == _vsnprintf
Hey Kai,
After applying r4737 both the syntax error and the missing wcslen export
in msvcrt.a are resolved! I'll continue with testing now (gcc 4.7 mass
rebuild for all Fedora packages) and report any other issues I may find
back to the list.
Thanks!
Erik van Pienbr
at
http://pkgs.fedoraproject.org/gitweb/?p=mingw32-boost.git
Kind regards,
Erik van Pienbroek
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
; tag used in naming 'struct _GMutex' [-fpermissive]
In file included from ../Source/JavaScriptCore/wtf/Platform.h:1123:0,
from ../Source/JavaScriptCore/config.h:30,
from ../Source/JavaScriptCore/API/JSBase.cpp:26:
../Source/JavaScriptCore/wtf/gobject/GType
ot)
mingw-w64: trunk (20120120 snapshot)
I expect the mass rebuild to complete in about 24 hours so I'll report
back once this mass rebuild has completed.
Kind regards,
Erik van Pienbroek
--
Keep Your Dev
Kevin Kofler schreef op vr 20-01-2012 om 18:39 [+0100]:
> Erik van Pienbroek wrote:
> > qt-4.8.0:
> >
> > In file included
> > from
> > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qbuiltinatomictypes_p.h:55:0,
> > from
or Fedora can be
found at [3]. This 'build recipe' builds a release/static copy, a
debug/shared copy, and a release/shared copy of Qt for both win32 and
win64 targets)
Kind regards,
Erik van Pienbroek
[1]:
http://pkgs.fedoraproject.org/gitweb/?p=mingw-qt.git;a=blob;f=qmake.conf.win32
[
ese
qt-style-windows* options will be enabled automatically
Kind regards,
Erik van Pienbroek
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landsc
es.patch;hb=HEAD
------
Author: Erik van Pienbroek (Fedora MinGW)
As we in Fedora are providing multiple copies of Qt (release/static,
debug/shared and release/shared) some manual fiddling is needed to make
all situations work. This patch is only of interest for package
maintainer
27;t upstreamed
yet. The patches [1][2] still have to be polished a bit more before it's
ready to be submitted upstream.
Regards,
Erik van Pienbroek
Fedora MinGW SIG
[1]:
http://pkgs.fedoraproject.org/gitweb/?p=mingw-qt.git;a=blob;f=qt-merge-static-and-shared-library-trees.patch;h=
ge
lacks a specific feature or is outdated, please let us know on the
Fedora MinGW mailing list (mi...@lists.fedoraproject.org) or IRC
(irc.freenode.net/#fedora-mingw) so that we can fix it.
Regards,
Erik van Pienbroek
Fedora MinGW SIG
---
even when
you've supplied the -static flag.
I just added the static pthread library to the mingw-pthreads package in
Fedora. You can fetch this package from
http://koji.fedoraproject.org/koji/buildinfo?buildID=329650
move files manually to their correct location. For details see
[1][2]. Initial tests are looking good. No regressions spotted so far
Regards,
Erik van Pienbroek
Fedora MinGW SIG
[1]:
http://pkgs.fedoraproject.org/gitweb/?p=mingw-headers.git;a=commitdiff;h=19c32c48f2904707e2caf
64.svn.sourceforge.net/viewvc/mingw-w64?view=revision&revision=5169
to be the culprit.
Is this really a regression or do you think it would be sufficient to
rebuild the Qt library?
Regards,
Erik van Pienbroek
Fedora MinGW SIG
mpiled packages which are already in Fedora and can be
redistributed easily. We were already planning to go this direction with
virtualised Windows guests in mind for more rapid testing of
applications so perhaps some goals can be combined here
Kind regards,
Erik van Pienbroek
Fedora MinGW SIG
[1
) and even major version numbers to mark stable releases (like
3.6.x). Perhaps something similar can be used for mingw-w64 too
Kind regards,
Erik van Pienbroek
--
WINDOWS 8 is here.
Millions of people
ed periodically but that shouldn't be too
hard of a problem.
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 t
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 and hopefully it should
> not affect any builds.
Yes, we also provide various large C++ libraries, like for
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.
> >>
> &g
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
===
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 -
2.0.999-0.15.trunk.20121110
- Update to 20121110 snapshot
* Fri Nov 09
--
* Tue Nov 27 2012 Erik van Pienbroek -
2.23.51.0.5-2
- Added BR: zlib-devel to enable support for compressed debug sections
* Wed Nov 21 2012 Erik van Pienbroek -
2.23.51.0.5-1
- Update to 2.23.51.0.5 release
mingw-cairo-1.12.8-1.fc19
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
> x86_6
since the previous rebuild:
mingw-boost-1.50.0-1.fc19
--
* Tue Dec 04 2012 Thomas Sailer - 1.50.0-1
- update to 1.50.0
- revert to bjam build
mingw-crt-2.0.999-0.16.trunk.20130105.fc19
---
* Sat Jan 05 2013 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 cross
.fc19,
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,
Eri
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 tru
installOEMInfA(PCSTR InfFileName,DWORD Flags,PVOID Reserved);
mingw-w64-headers/include/setupapi.h: WINSETUPAPI WINBOOL WINAPI
SetupUninstallOEMInfW(PCWSTR InfFileName,DWORD Flags,PVOID Reserved);
Can somebody of the mingw-w64 devs indicate wheth
===
The following packages were updated since the previous rebuild:
mingw-angleproject-0-0.4.svn1561.20121214.fc19
---
* Thu Apr 04 2013 Erik van Pienbroek -
0-0.4.svn1561.20121214
- Added another workaround due to the fact that the gyp
build system
against the mingw-cairo
component is also good.
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
.org/show_bug.cgi?id=698118
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
a
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 se
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 the previous
> mass rebuild **
> Package owner: rjones
> Tim
===
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 -
2.0.999-0.20.trunk.20130425
- Update to 20130425 snapshot
mingw-eigen3
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
> >>
JonY schreef op zo 28-04-2013 om 10:44 [+0800]:
> On 4/28/2013 00:11, JonY wrote:
> > On 4/27/2013 22:40, Dongsheng Song wrote:
> >>
> >> I think mingw-w64 should not use C++ linkage for these C functions
> >> when use C++ compiler.
> >
>
> Done, moved.
With mingw-w64 commit r5822 the gettext/a
ion 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 r
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
-2.0.999-0.23.trunk.20130509.fc19
---
* Thu May 09 2013 Erik van Pienbroek -
2.0.99-0.23.trunk.20130509
- Regenerated 20130509 snapshot
- Dropped upstreamed vsprintf_s patch
* Thu May 09 2013 Erik van Pienbroek -
2.0.999-0.22.trunk.20130509
- Update to
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 Fed
onfiguration is necessary (it's sufficient to open the package manager,
search for 'mingw32-gcc' and press the install button).
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
AlienVault Unified Secu
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
threads. A more
suitable place for these
symbols would 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
s/009695399/functions/pthread_sigmask.html
Can we 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 servic
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
>
> [O
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
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
.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
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
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
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
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 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.
>
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 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
.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,
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
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
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
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
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
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
===
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
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
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
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
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
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
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
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
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 #
> 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
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
>
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 **
> &
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
> >
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
>
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
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 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 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 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
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
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
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.
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
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
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
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
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
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"
.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
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
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
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
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
>
1 - 100 of 150 matches
Mail list logo
