Re: [Mingw-w64-public] Mass rebuild report for May 11 2016
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-mingw-rebuild/20160511/mingw-clucene-2.3.3.4-14
CMake Error at src/shared/cmake/MacroEnsureVersion.cmake:27 (MATH):
math cannot parse the expression: "x86_64-w64-mingw326*1 +
x86_64-w64-mingw321*100 + x86_64-w64-mingw320": syntax error, unexpected
exp_NUMBER, expecting $end (7)
Call Stack (most recent call first):
src/shared/cmake/MacroCheckGccVisibility.cmake:35 (macro_ensure_version)
src/core/CMakeLists.txt:10 (MACRO_CHECK_GCC_VISIBILITY)
This sounds an issue where the version of the GCC compiler (6.1.0) can't be
detected properly by the CMake script.
> mingw-cximage-600-14
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: elmarco
> Time to build: 45 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-cximage-600-14
i686-w64-mingw32-g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -D_USRDLL -D_USRCxImageCrtDll -DCxImageCrtDll_EXPORTS
-shared -o libcximage.dll -Wl,--out-
implib,libcximage.dll.a ../CxImage/tif_xfile.cpp ../CxImage/ximabmp.cpp
../CxImage/ximadsp.cpp ../CxImage/ximaenc.cpp ../CxImage/ximaexif.cpp
../CxImage/ximage.cpp ../CxImage/ximagif.cpp
../CxImage/ximahist.cpp ../CxImage/ximaico.cpp ../CxImage/ximainfo.cpp
../CxImage/ximaint.cpp ../CxImage/ximajas.cpp ../CxImage/ximajbg.cpp
../CxImage/ximajpg.cpp ../CxImage/ximalpha.cpp
../CxImage/ximalyr.cpp ../CxImage/ximamng.cpp ../CxImage/ximapal.cpp
../CxImage/ximapcx.cpp ../CxImage/ximapng.cpp ../CxImage/ximaraw.cpp
../CxImage/ximasel.cpp ../CxImage/ximaska.cpp
../CxImage/ximatga.cpp ../CxImage/ximath.cpp ../CxImage/ximatif.cpp
../CxImage/ximatran.cpp ../CxImage/ximawbmp.cpp ../CxImage/ximawmf.cpp
../CxImage/ximawnd.cpp ../CxImage/xmemfile.cpp
../CxImage/CxImageDLL/CxImageCrtDll.cpp -lgdi32 -lws2_32 -ljpeg -ltiff -ljasper
-I/usr/i686-w64-mingw32/sys-root/mingw/include/libpng16
-I/usr/i686-w64-mingw32/sys-root/mingw/include -L/usr/i686-w64-
mingw32/sys-root/mingw/lib -lpng16 -lz
In file included from
/usr/i686-w64-mingw32/sys-root/mingw/include/c++/deque:60:0,
from /usr/i686-w64-mingw32/sys-root/mingw/include/c++/queue:60,
from ../CxImage/ximadsp.cpp:3457:
/usr/i686-w64-mingw32/sys-root/mingw/include/c++/bits/stl_algobase.h:243:56:
error: macro "min" passed 3 arguments, but takes just 2
min(const _Tp& __a, const _Tp& __b, _Compare __comp)
This failure is likely caused by a compatibility issue with GCC6
> mingw-LibRaw-0.17.1-2
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: smani
> Time to build: 52 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-LibRaw-0.17.1-2
../internal/dcraw_common.cpp: In member function 'void
LibRaw::vng_interpolate()':
../internal/dcraw_common.cpp:4539:3: error: narrowing conversion of '128' from
'int' to 'signed char' inside { } [-Wnarrowing]
}, chood[] = { -1,-1, -1,0, -1,+1, 0,+1, +1,+1, +1,0, +1,-1, 0,-1 };
^
This one is probably caused by more strict behavior of GCC6
> mingw-llvm-3.0-11
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: brouhaha
> Time to build: 4 minutes, 31 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-llvm-3.0-11
/builddir/build/BUILD/llvm-3.0.src/tools/bugpoint/ToolRunner.cpp: In function
'int RunProgramRemotelyWithTimeout(const llvm::sys::Path&, const char**, const
llvm::sys::Path&, const llvm::sys::Path&,
const llvm::sys::Path&, unsigned int, unsigned int)':
/builddir/build/BUILD/llvm-3.0.src/tools/bugpoint/ToolRunner.cpp:131:12: error:
no match for 'operator<<' (operand types are 'llvm::raw_ostream' and
'std::ostringstream {aka
std::__cxx11::basic_ostringstream}')
errs() << OS;
~~~^
Also sounds like more strict behavior of GCC6
> mingw-OpenEXR-2.2.0-3
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: smani
> Time to build: 1 minute, 7 seconds
> Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-OpenEXR-2.2.0-3
i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../exrenvmap -I../config -I..
-I../../IlmImf -I../../config
-I/usr/i686-w64-mingw32/sys-root/mingw/include/OpenEXR-pipe -O2 -g -pipe
-Wall -Wp,-
D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-s
Re: [Mingw-w64-public] undefined reference to `IID_IMultiLanguage'
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't work.. -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] undefined reference to `IID_IMultiLanguage'
Hey, I'm currently trying to get the latest qtwebkit (5.6.0) built against mingw-w64 v5.0rc2, but I'm getting the following linker error: TextCodecWin.cpp:85: undefined reference to `IID_IMultiLanguage' I'm wondering whether I'm running into a mingw-w64 bug here or whether something needs to be fixed in qtwebkit. A grep on the mingw-w64 headers shows that this symbol is declared in mlang.h I can confirm that the qtwebkit code in question is also including this header. MSDN ( https://msdn.microsoft.com/en-us/library/aa741022%28v=vs.85%29.a spx ) doesn't 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 with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] release possible
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 Fedora I already investigated backporting the various commits which are required for wine-gecko 2.44. Here's the list for commits which have to be applied on top of mingw-w64 4.0.4: mingw-w64-headers: ace70f1 dcb7580 3f14056 7b225ae 44bd1f9 9e48507 7a2e581 790a654 67bb96f mingw-w64-crt: ac13c19 This is in addition to the 14 commits which I already backported earlier (also on top of mingw-w64 4.0.4, the list can be found in the mingw-w64 mailing list archives) to get wine-gecko 2.40 built on Fedora. Regards, Erik -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Wine Gecko 2.40-beta1
Jacek Caban schreef op ma 06-07-2015 om 17:24 [+0200]: Hi all, I'm forwarding this announcement to mingw-w64 ML, because I know that a few disto maintainers read it. The final release will be in about 5 -6 weeks, so it's a good moment to ensure that it builds correctly. All feedback is appreciated. Thanks, Jacek Hi Jacek, For Fedora we just tried to get the latest wine-gecko built. In order to get it built successfully against the recently released mingw-w64 v4.0.4 we had to manually backport the following commits: 7eee339 - msinkaut.idl: Added new file. fc960d3 - msinkaut.h: Generated header file. ef5e914 - msinkaut_i.c: Added new file. 4ce7a79 - Install *.c files as headers as well. 85b4034 - textstor.idl: Updated to current Wine version. a883b47 - Added new versionhelpers.h header. e4a8812 - d2d1_1helper.h: Added a few missing declarations. e960f8f - winsdkver.h: Added *_WINBLUE defines. c440466 - Added liblocationapi.a. Could somebody please backport these commits to the v4.x branch? A bit offtopic (not wine-gecko related) but could somebody also please backport the following commit? It is needed by qt5-qtactiveqt 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.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling SDL2
Christer Solskogen schreef op ma 27-04-2015 om 19:37 [+0200]: Hi! I've got trouble cross compiling SDL2 with the latest and greatest gcc, binutils and mingw-w64. gcc version 5.1.0 (GCC) GNU ld (GNU Binutils) 2.25 and mingw-w64 v4.x (from git) I don't what is to blame. But I'm pretty sure the cross compiler it self is in good shape, since I can cross compile SDL1 without any issues. Hi, This is a known issue in SDL2 (which was also mentioned on this mailing list multiple times). On the mingw-w64 side you 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 -duplicate-d3d11-declarations.patch Regards, Erik van Pienbroek Fedora MinGW SIG -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0.0 released
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 and came up with a couple of patches which implement the missing D3D11 features which are required by SDL2 and which also fix two issues in SDL2 itself (duplicate d3d11 declarations and a gcc macro issue). I've just sent these patches to Jacek for review and approval so they should show up in wine and mingw-w64 soon. Regards, Erik -- 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
[Mingw-w64-public] Mass rebuild report for March 08 2015
This is a report for the 20150308 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 v4.0rc3 * binutils 2.25 * gcc 5 20150301 snapshot (rev 221092) Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20150308 Total packages: 219 Number of failed packages: 12 Number of succeeded packages: 207 Number of added packages since previous mass rebuild: 1 Time needed to perform mass rebuild: 12 hours, 25 minutes, 38 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20150130 Total packages: 218 Number of failed packages: 4 Number of succeeded packages: 214 === The following packages were added since the previous rebuild: mingw-SDL2_image === 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: 55 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-angleproject-0-0.11.git.30d6c2.20141113 mingw-clucene-2.3.3.4-10 Package owner: greghellings Time to build: 2 minutes, 18 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-clucene-2.3.3.4-10 mingw-gstreamer1-plugins-good-1.4.4-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: elmarco Time to build: 3 minutes, 5 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-gstreamer1-plugins-good-1.4.4-1 mingw-gtk3-3.14.5-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 5 minutes, 53 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-gtk3-3.14.5-1 mingw-libgpg-error-1.12-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 1 minute, 2 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-libgpg-error-1.12-2 mingw-qt-4.8.6-6 Package owner: sailer Time to build: 26 minutes, 14 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-qt-4.8.6-6 mingw-qt5-qtwebkit-5.4.0-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 6 minutes, 37 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-qt5-qtwebkit-5.4.0-1 mingw-SDL2-2.0.3-4 Package owner: maci Time to build: 1 minute, 29 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-SDL2-2.0.3-4 mingw-webkitgtk-2.2.8-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 2 minutes, 6 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-webkitgtk-2.2.8-1 mingw-webkitgtk3-2.2.8-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 2 minutes, 10 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-webkitgtk3-2.2.8-1 mingw-wine-gecko-2.36-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: awjb Time to build: 21 minutes, 8 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-wine-gecko-2.36-1 wine-mono-4.5.6-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: awjb Time to build: 5 minutes, 57 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/wine-mono-4.5.6-1 === 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 - * Wed Feb 11 2015 Greg Hellings greg.helli...@gmail.com - 0.104-1 - New upstream version mingw-gcc-5.0.0-0.1.svn.20150301.r221092.fc21
Re: [Mingw-w64-public] Mass rebuild report for March 08 2015
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: 55 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-angleproject-0-0.11.git.30d6c2.20141113
+ gyp -D OS=win -D TARGET=win32 -D MSVS_VERSION= --depth .
-I ../build/common.gypi ../src/angle.gyp
Traceback (most recent call last):
File /usr/bin/gyp, line 5, in module
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
Apparently gyp is broken in Fedora rawhide, not mingw related
mingw-clucene-2.3.3.4-10
Package owner: greghellings
Time to build: 2 minutes, 18 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-clucene-2.3.3.4-10
Also failed in previous test mass rebuild. Fix is ready but hasn't been
pushed yet
mingw-gstreamer1-plugins-good-1.4.4-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: elmarco
Time to build: 3 minutes, 5 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-gstreamer1-plugins-good-1.4.4-1
RPM build errors:
File not
found:
/builddir/build/BUILDROOT/mingw-gstreamer1-plugins-good-1.4.4-1.fedora_rebuild_20150308.i386/usr/i686-w64-mingw32/sys-root/mingw/lib/gstreamer-1.0/libgstgdkpixbuf.dll
This is a packaging issue
mingw-gtk3-3.14.5-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: kalev
Time to build: 5 minutes, 53 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-gtk3-3.14.5-1
libtool: error: can't build i686-w64-mingw32 shared library unless
-no-undefined is specified
Makefile:1126: recipe for target 'libgtkreftestprivate.la' failed
This is probably triggered by a more modern libtool/autofoo in Fedora
Rawhide. Will probably get resolved at the next gtk+ update
mingw-libgpg-error-1.12-2
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: rjones
Time to build: 1 minute, 2 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-libgpg-error-1.12-2
cc -I. -I../../src -o mkerrcodes ../../src/mkerrcodes.c
In file included from ../../src/mkerrcodes.c:26:0:
./mkerrcodes.h:9:5: error: expected expression before ',' token
{ , GPG_ERR_E2BIG },
^
./mkerrcodes.h:10:5: error: expected expression before ',' token
{ , GPG_ERR_EACCES },
^
Not sure what's wrong here. Needs more research..
mingw-qt-4.8.6-6
Package owner: sailer
Time to build: 26 minutes, 14 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-qt-4.8.6-6
Known issue which was also present in previous test mass rebuild. Still
needs to be fixed
mingw-qt5-qtwebkit-5.4.0-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: epienbro
Time to build: 6 minutes, 37 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-qt5-qtwebkit-5.4.0-1
Warning: resolving _cti_vm_throw by linking to @cti_vm_throw@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
/builddir/build/BUILD/qtwebkit-opensource-src-5.4.0/build_win32/Source/JavaScriptCore/release/libJavaScriptCore.a(JSArray.o):
In function `ZN3JSC7JSArray4pushEPNS_9ExecStateENS_7JSValueE':
/builddir/build/BUILD/qtwebkit-opensource-src-5.4.0/Source/JavaScriptCore/runtime/JSArray.cpp:584:
undefined reference to `void
JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes(unsigned
char)20(JSC::ExecState*, unsigned int, JSC::JSValue)'
collect2: error: ld returned 1 exit status
Makefile.jsc.Release:80: recipe for target '../../bin/jsc.exe' failed
Not sure why this suddenly shows up. Based in the list of changed
packages (below in the report) I would suspect gcc 5 being responsible
for triggering this failure.
mingw-SDL2-2.0.3-4
Package owner: maci
Time to build: 1 minute, 29 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-SDL2-2.0.3-4
Known failure, SDL2 tries to re-implement IDXGIFactory2 and
ID3D11Device1 which were added to mingw-w64 recently. Needs to be fixed
in SDL2 itself.
mingw-webkitgtk-2.2.8-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: epienbro
Time to build: 2 minutes, 6 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-webkitgtk-2.2.8-1
configure: error: Compiler
Re: [Mingw-w64-public] trouble getting mingw setup
David Rysdam schreef op ma 23-02-2015 om 09:32 [-0500]: I have a project I want to cross compile for Win64 from my Linux machine (x86_64 CentOS 6.5 eventually, but x86_64 Debian 7 for the below test). For reasons, life will be much better and easier for me if I compile the toolchain from source. (I know that on Debian I can apt-get install, but I'm testing the compile instructions here before I move elsewhere.) You could save yourself a lot of trouble and headaches by trying out the large collection of mingw packages which are already available 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/Tutorial Regards, Erik van Pienbroek -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
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. Is there still interest in doing another test mass rebuild against the latest gcc 5 snapshot before releasing mingw-w64 v4.0? Apparently gcc 5 is busted at the moment (20150125 snapshot, svn r220097) as it fails to build with this error: make[4]: Entering directory '/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp' /bin/sh ./libtool --tag=CC --mode=compile /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc -B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32 -I../../../libgomp/config/posix -I../../../libgomp -I../../../libgomp/../include -Wall -Werror -Wc,-pthread -g -O2 -MT target.lo -MD -MP -MF .deps/target.Tpo -c -o target.lo ../../../libgomp/target.c libtool: compile: /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc -B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32 -I../../../libgomp/config/posix -I../../../libgomp -I../../../libgomp/../include -Wall -pthread -Werror -g -O2 -MT target.lo -MD -MP -MF .deps/target.Tpo -c ../../../libgomp/target.c -DDLL_EXPORT -DPIC -o .libs/target.o ../../../libgomp/target.c: In function 'gomp_map_vars': ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] gomp_fatal (present clause: !acc_is_present (%p, ^ ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] ../../../libgomp/target.c:440:21: error: too many arguments for format [-Werror=format-extra-args] cc1: all warnings being treated as errors Makefile:613: recipe for target 'target.lo' failed make[4]: *** [target.lo] Error 1 make[4]: Leaving directory '/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp' The offending line contains this piece of code: gomp_fatal (present clause: !acc_is_present (%p, %zd (0x%zx)), (void *) k-host_start, size, size); I have no idea whether this is a gcc issue or a mingw-w64 one... -- 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] time guard
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 breakage this is the cause. I'm currently doing a mass rebuild test run with mingw-w64 v4.0rc1 including the patch mentioned in this thread. It takes around 24hours to prepare and complete such a test mass rebuild. I wasn't really planning on also doing a test mass rebuild with plain v4.0rc1 (without the patch). However, I do was planning to introduce GCC 5 in Fedora soon (the native gcc in Fedora was also just updated to the latest GCC 5 snapshot) and use this to do another test mass rebuild. Regards, Erik -- 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
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
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
[Mingw-w64-public] Mass rebuild report for January 30 2015
This is a report for the 20150130 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 v4.0rc1 with localtime_s/asctime_s patch * binutils 2.25 * gcc 4.9.2 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20150130 Total packages: 218 Number of failed packages: 4 Number of succeeded packages: 214 Number of added packages since previous mass rebuild: 5 Time needed to perform mass rebuild: 19 hours, 58 minutes, 25 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20150103 Total packages: 213 Number of failed packages: 16 Number of succeeded packages: 197 === The following packages were added since the previous rebuild: mingw-libIDL mingw-qt5-qtenginio mingw-qt5-qtwebchannel mingw-qt5-qtwebsockets mingw-sword === 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 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 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 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 === The following packages were updated since the previous rebuild: mingw-colord-1.2.8-1.fc21 -- * 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 -- * Sat Jan 24 2015 Sandro Mani manisan...@gmail.com - 3.2.4-1 - Update to release 3.2.4 mingw-gcc-4.9.2-2.fc21 --- * Thu Jan 29 2015 Erik van Pienbroek epien...@fedoraproject.org - 4.9.2-2 - The package cloog-ppl-devel was renamed to cloog-devel in rawhide mingw-glib2-2.43.3-1.fc21 -- * Mon Jan 26 2015 Erik van Pienbroek epien...@fedoraproject.org - 2.43.3-1 - Update to 2.43.3 mingw-headers-4.0-0.2.rc1.fc21 --- * Wed Jan 28 2015 Erik van Pienbroek epien...@fedoraproject.org - 4.0-0.2.rc1 - Fix localtime_s and asctime_s compatibility issue * Mon Jan 26 2015 Erik van Pienbroek epien...@fedoraproject.org - 4.0-0.1.rc1 - Update to 4.0rc1 mingw-jasper-1.900.1-26.fc21 - * Thu Jan 22 2015 Michael Cronenworth m...@cchtml.com - 1.900.1-26 - Fixes for CVE-2014-8157 and CVE-2014-8158 mingw-libgusb-0.2.4-1.fc21 --- * Fri Jan 09 2015 Richard Hughes rich...@hughsie.com 0.2.4-1 - New upstream version - Add new API for various client programs - Don't filter out hub devices when getting the device list - Make the platform ID persistent across re-plug mingw-libmicrohttpd-0.9.34-4.fc21 -- * Sat Jan 03 2015 Michael Cronenworth m...@cchtml.com - 0.9.34-4 - Drop plibc mingw-libtheora-1.1.1-2.fc21 - * Sun Jan 04 2015 Franti?ek Dvo?ák val...@civ.zcu.cz - 1.1.1-2 - Build with the newest toolchain mingw-libvirt-1.2.12-1.fc21 * Tue Jan 27 2015 Daniel P. Berrange berra...@redhat.com - 1.2.12-1 - Update to 1.2.12 release mingw-poppler-0.30.0-2.fc21 * Tue Jan 27 2015 Sandro Mani manisan...@gmail.com - 0.30.0-2 - Re-enable openjpeg support * Tue Jan 27 2015 Sandro Mani manisan...@gmail.com - 0.30.0-1 - Update to 0.30.0 mingw-qt5-qtbase-5.4.0-4.fc21 -- * Mon Jan 26 2015 Erik van Pienbroek epien...@fedoraproject.org - 5.4.0-4 - Rebuild against mingw-w64 v4.0rc1 mingw-qt5-qtfeedback-5.0.0-0.10.git20140527.dea0da72.fc21 -- * Sun Jan 04 2015 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.10.git20140527.dea0da72 - Fixed
Re: [Mingw-w64-public] v4.0-rc1 released
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 give it a spin! Thanks for the pre-release! I'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 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] v4.0-rc1 released
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 give it a spin! Thanks for the pre-release! I'm going to push it to Fedora rawhide and Fedora 21 testing. Afterwards another iteration of the test mass rebuild can be performed. Initial testing has shown that static libraries which were built against an older mingw-w64 trunk snapshot may need to be rebuilt. For example the static qt5-qtbase libraries in Fedora 21 and rawhide cannot be used any more as can be observed at http://build1.vanpienbroek.nl:8080/job/fedora_mingw_testsuite_rawhide/717/testReport/junit/fedora_mingw_testsuite/qt5_qmake/qt_qmake_test_static_mingw32/ This seems to be caused by the fact that packages like this were built against a mingw-w64 trunk snapshot where the symbol localtime_r still was part of the mingw-w64-crt libraries. I guess this is an intentional change and the solution is to rebuild the affected packages against 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 03 2015
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 implementation has one more problem. We can't really have localtime_r, because it needs to depend on _USE_32BIT_TIME_T macro. So if we really wanted to have a real function in mingwex, we'd need it as localtime32_r and localtime64_r and an inline wrapper. Given that, I think we should live with inline implementation. Esp. since we may use localtime_s (which already has wrapper inline as well as compatibility stub in libmsvcrt.a), which makes the implementation trivial. Please review the attached patch. I believe we should do the same for ctime_r and asctime_r. Hi Jacek, Thanks for the patch. I just tested it and I can confirm that it solves the localtime_r issue in glib2 and the gmtime_r issues in libgsf and libsoup. The cmtime_r issue in cairo is not resolved yet with this patch, but I guess this is expected for now. However, there are now other issues which prevent glib2 from building successfully (libgsf and libsoup built just fine). For glib2: ../../gio/gsocket.c:1934:1: error: conflicting types for 'if_nametoindex' if_nametoindex (const gchar *iface) ^ In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/iphlpapi.h:16:0, from ./gnetworking.h:35, from ../../gio/gnetworkingprivate.h:22, from ../../gio/gsocket.c:60: /usr/i686-w64-mingw32/sys-root/mingw/include/netioapi.h:321:20: note: previous declaration of 'if_nametoindex' was here NET_IFINDEX WINAPI if_nametoindex( ^ My first guess is that this needs to be fixed in glib2 itself and that it is unrelated to your patch Regards, Erik -- 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
[Mingw-w64-public] Mass rebuild report for January 03 2015
Time to build: 2 minutes, 2 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt5-qtsystems-5.0.0-0.14.git20140323.3f65ffa mingw-sigar-1.6.5-0.13.git58097d9 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: beekhof Time to build: 20 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-sigar-1.6.5-0.13.git58097d9 mingw-spice-gtk-0.27-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: elmarco Time to build: 1 minute, 50 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-spice-gtk-0.27-3 mingw-wpcap-4.1.final2-13 Package owner: sailer Time to build: 30 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-wpcap-4.1.final2-13 === The following packages were updated since the previous rebuild: mingw-OpenEXR-2.2.0-1.fc21 --- * Wed Nov 26 2014 Sandro Mani manisan...@gmail.com - 2.2.0-1 - Update to 2.2.0 mingw-angleproject-0-0.11.git.30d6c2.20141113.fc21 --- * 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-qt5-qtwebkit 5.4 mingw-atk-2.15.3-1.fc21 * Thu Jan 01 2015 Erik van Pienbroek epien...@fedoraproject.org - 2.15.3-1 - Update to 2.15.3 * Tue Oct 14 2014 Kalev Lember kalevlem...@gmail.com - 2.14.0-1 - Update to 2.14.0 * Sun Sep 21 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.13.90-1 - Update to 2.13.90 mingw-binutils-2.25-1.fc21 --- * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.25-1 - Update to 2.25 * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.24-5 - Fix CVE-2014-8501 (RHBZ #1162578 #1162583) - Fix CVE-2014-8502 (RHBZ #1162602) - Fix CVE-2014-8503 (RHBZ #1162612) - Fix CVE-2014-8504 (RHBZ #1162626) - Fix CVE-2014-8737 (RHBZ #1162660) - Fix CVE-2014-8738 (RHBZ #1162673) mingw-cairo-1.14.0-1.fc22 -- * Thu Jan 01 2015 Erik van Pienbroek epien...@fedoraproject.org - 1.14.0-1 - Update to 1.14.0 * Thu Jan 01 2015 Erik van Pienbroek epien...@fedoraproject.org - 1.12.18-1 - Update to 1.12.18 mingw-crt-3.9.999-0.5.trunk.git.f7337b.20141222.fc21 - * Mon Dec 22 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.9.999-0.5.trunk.git.f7337b.20141222 - Update to 20141222 snapshot (git rev f7337b) * Tue Dec 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.9.999-0.4.trunk.git.dadc8f.20141209 - Update to 20141209 snapshot (git rev dadc8f) * Wed Dec 03 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.9.999-0.2.trunk.git.a5c151.20141203 - Update to 20141203 snapshot (git rev a5c151) * Fri Sep 12 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.9.999-0.1.trunk.git.b08afb.20140912 - Update to 20140912 snapshot (git rev b08afb) - Bump version as upstream released mingw-w64 v3.2.0 recently (which is not based on the trunk branch) mingw-curl-7.39.0-1.fc21 - * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 7.39.0-1 - Update to 7.39.0 - Fixes CVE-2014-3707 (RHBZ #1160724) - Fixes CVE-2014-3620 CVE-2014-3613 (RHBZ #1140037) mingw-dbus-1.8.12-1.fc21 - * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 1.8.12-1 - Update to 1.8.12 * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 1.6.28-1 - Update to 1.6.28 - Fixes CVE-2014-7824 (RHBZ #1173557) - Fixes CVE-2014-3638 CVE-2014-3639 CVE-2014-3636 CVE-2014-3637 and CVE-2014-3635 (RHBZ #1142582) - Fixes CVE-2014-3477 (RHBZ #1117395) - Fixes CVE-2014-3533 CVE-2014-3532 (RHBZ #1115637) mingw-eigen3-3.2.3-1.fc21 -- * Thu Dec 18 2014 Sandro Mani manisan...@gmail.com - 3.2.3-1 - Update to release 3.2.3 * Mon Aug 04 2014 Sandro Mani manisan...@gmail.com - 3.2.2-1 - Update to release 3.2.2 mingw-flac-1.3.1-1.fc21 * Thu Nov 27 2014 David King amigad...@amigadave.com - 1.3.1-1 - Update to 1.3.1 (#1168768) - Fixes CVE-2014-8962 and CVE-2014-9028 mingw-freeimage-3.15.4-5.fc21 -- * Wed Nov 26 2014 Sandro Mani manisan...@gmail.com - 3.15.4-5 - Rebuild (ilmbase, OpenEXR) mingw-freetype-2.5.4-1.fc21 * Tue Dec 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.5.4-1 - Update to 2.5.4 - Fixes RHBZ #1172635 * Thu Jul 10 2014 Nicola Fontana n...@entidi.it - 2.5.3-3 - Update subpixel rendering patch
Re: [Mingw-w64-public] Mass rebuild report for January 03 2015
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 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-cairo-1.14.0-1 Failed with: implicit declaration of function 'ctime_r' mingw-clucene-2.3.3.4-10 Package owner: greghellings Time to build: 1 minute, 41 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-clucene-2.3.3.4-10 Also failed in the previous test mass rebuild, package apparently is trying to work around previously missing toolchain features which cause breakage on modern mingw-w64 environments: /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/_threads.h:55:104: error: conflicting declaration of C function 'void* _beginthread(void (__attribute__((__stdcall__)) *)(void*), unsigned int, void*)' Needs to be fixed in CLucene upstream mingw-glib2-2.42.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 4 minutes, 7 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glib2-2.42.1-1 Failed with: implicit declaration of function 'localtime_r' mingw-glibmm24-2.43.2-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 38 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glibmm24-2.43.2-1 Failed with: Requested 'glib-2.0 = 2.43.1' but version of GLib is 2.42.1 Is caused by the mingw-glib2 build failure mentioned above mingw-libgsf-1.14.30-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 1 minute, 3 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libgsf-1.14.30-2 Failed with: implicit declaration of function 'gmtime_r' mingw-libmicrohttpd-0.9.34-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: mooninite Time to build: 9 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libmicrohttpd-0.9.34-3 Error: No Package found for mingw32-plibc Error: No Package found for mingw64-plibc Seems to be caused by the mingw-plibc package being removed from Fedora Rawhide mingw-libsoup-2.48.0-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 57 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libsoup-2.48.0-2 Failed with: implicit declaration of function 'gmtime_r' mingw-libtheora-1.1.1-1 Package owner: valtri Time to build: 55 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libtheora-1.1.1-1 Failed with: error: static declaration of 'rint' follows non-static declaration (examples/encoder_example.c vs. mingw-w64 math.h) Needs to be fixed in libtheora upstream 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.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-poppler-0.28.1-1 Failed with: error: 'gmtime_r' was not declared in this scope mingw-qt-4.8.6-6 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 23 minutes, 1 second Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt-4.8.6-6 Failed 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' Seems to be caused by the update to dbus 1.8.12. Might need an additional -liphlpapi somewhere. mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 1 minute, 21 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72 File not found: /builddir/build/BUILDROOT/mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72.fedora_rebuild_20150102.i386/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt0Feedback.dll File
Re: [Mingw-w64-public] Changes needed to get wine-gecko 2.34 built against mingw-w64 v3.3.0
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 attached 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch 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. I don't see the problem here. I remember fixing some version handling version macros for similar reason. Maybe 4d7b86c46 would help. Hi Jacek, I tried building wine-gecko without the 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch workaround which I mentioned in my initial post and replaced it with a cherry-pick of commit 4d7b86c46. Unfortunately this combination fails with: /home/erik/fedora/mingw-wine-gecko/mingw-wine-gecko-2.34/wine-mozilla-2.34/hal/windows/WindowsBattery.cpp:24:17: error: 'RegisterPowerSettingNotification' was not declared in this scope static decltype(RegisterPowerSettingNotification)* sRegisterPowerSettingNotification = nullptr; 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? I'm not really involved in stable branches. That's quite a few patches to cherry-pick, so it's not something an usual stable branch should take. On the other hand, if stable releases are so rare, maybe existing stable releases should take more cherry-picks. I agree that the amount of changes is quite large and that is is questionable whether this really is material for the v3.x branch..but on the other hand it is the only realistic option we have if we want to be able to get the latest wine working in Fedora 20. Maybe we could find some long term solution. How did you deal with mingw-w64 requirements in the past, when wine-gecko was released every three months? How hard would it be to use some version off the master branch just for wine-gecko? In the mailing list thread RFE: New stable release I just tried to explain how we do things in Fedora (it's a bit off-topic for this specific thread). Unfortunately it isn't possible to use a custom version of mingw-w64 specifically to get wine-gecko built on older Fedora releases. It's basically all or nothing: if we update mingw-w64 in a Fedora branch then all other mingw packages and all mingw users are forced to use it. In the past we did also have issues with getting wine-gecko built but these were pretty minor compared to the one we're having now with wine-gecko 2.34. These minor issues could be pretty easily be resolved with minor changes in either mingw-w64 or wine-gecko. Regards, Erik -- 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] RFE: New stable release
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 release and if it brings new things then work towards a feature release. This is basically a follow-up on the thread Changes needed to get wine-gecko 2.34 built against mingw-w64 v3.3.0, but as I consider it off-topic for that other thread I'll reply here. In Fedora we maintain multiple Fedora releases. The life cycle of Fedora releases is explained at https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle and https://fedoraproject.org/wiki/Releases At the moment we maintain 3 different Fedora releases/branches: Fedora 20, Fedora 21 (released last month) and Fedora Rawhide (which will become Fedora 22 around May/June 2015). In Fedora Rawhide (the development branch) we're always using the latest mingw-w64 master snapshot (which I update from time to time and also use for the mass rebuild tests). As there have been no stable mingw-w64 releases since the moment Fedora 21 which was branched from rawhide (July 2014) the mingw-w64 version which is used in Fedora is a mingw-w64 master snapshot. This pattern was also used for Fedora 20. However, the stable mingw-w64 v3.0.0 was released around that time (Sept 2013) so it was decided to stick with the v3.x branch for Fedora 20. Because of this decision we're currently at mingw-w64 v3.3.0 in the Fedora 20 branch. It would definitely help us when mingw-w64 would do more frequent releases. All major Linux distributions have two major releases per year. One around April and one around October. Many large open source projects (like GNOME) have made their development cycles line up with this schedule. In Fedora there's also the rule that once a new major Fedora version is released (say: Fedora 21) then the Fedora version which was released 2 cycles ago (say: Fedora 19) will become EOL and will receive no further updates and support. Perhaps such a release cycle could be introduced for mingw-w64 as well Regards, Erik -- 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
[Mingw-w64-public] Changes needed to get wine-gecko 2.34 built against mingw-w64 v3.3.0
Hi,
In Fedora 20 we're using mingw-w64 v3.3.0. While trying to get the
latest wine-gecko built (2.34) we noticed that quite a lot of features
were missing from the mingw-w64 v3.x branch which are already part of
the master branch (this was also the trigger for the RFE: New stable
release thread which was started on this mailing list on December 15).
Without these features it isn't possible to build wine-gecko 2.34.
As it turns out a new stable release (based on the master branch) is not
expected soon we at Fedora decided to investigate the possibility to
backport all the required changes manually to the v3.x branch as the
updated wine-gecko is required by the latest wine which we want to make
available in Fedora 20.
Some days ago a list was generated with missing features in mingw-w64
v3.3.0 (thanks to Michael Cronenworth) and I searched for all the
relevant commits in the git history.
Here is the list of commits which need to be applied on top of mingw-w64
v3.3.0 to get wine-gecko 2.34 built:
mingw-w64-headers:
a77e5c - mfapi.h: Moved MFCreateAttributes to mfapi.h, where it belongs.
3418d7 - Update mfobjects interface for winapi-family and W8
262537 - Updated imported headers to current Wine version.
b50bef - Updated headers imported from Wine
e9951e - winerror.h: Added some missing error codes.
3f6863 - d2d1_1helper.h: Added some missing helpers.
d348ce - Updated imported headers to current Wine version.
0c890e - winsdkver.h: Added new header.
4ea90e - dwrite_1.h: Added new header file.
435391 - Added some missing WMF declarations.
81a63d - mstcpip.h: Declare RtlIpv6* functions only if ws2ipdef.h is...
77b2e1 - Added dxgi1_2.h missing in previous commit.
e08002 - Updated imported headers to current Wine version.
ea45fb - tsattrs.h: Added new header file.
b93317 - Add winapifamily-check, correct enumerator values, add...
8fff41 - Updated imported headers to current Wine version.
bf99de - Add comadmin.idl to Makefile.am and regenerate files.
017715 - Updated imported headers to current Wine version.
9c0a7a - Updated imported headers to current Wine version.
1c64f4 - Fixed some version guards.
6f7b01 - dwrite.h: Don't duplicate parent interface methods for C++...
ae2e05 - string_s.h/wchar_s.h: Added wcsnlen_s implementation.
a5d3ef - Use __forceinline for wcsnlen_s implementation.
2d16d4 - Updated imported headers to current Wine version.
mingw-w64-crt:
2bbc22 - Added 32-bit version of libwintrust.a.
3dc34b - uuid.c: Added missing urlmon CLSIDs and get rid of duplicated
IIDs
Almost all these commits can be directly cherry-picked to the v3.x
branch without conflicts. The only exceptions are the last one from
mingw-w64-headers (2d16d4) for which only the dxgi.h parts are necessary
and for the two mingw-w64-crt changes the Makefile.in changes don't
apply cleanly (these can be regenerated by automake). For these 3
commits I've attached updated .patch files to this mail.
Another thing I noticed is a possible typo which was introduced in
commit b35450 (Add winapi-family feature, added missing Windows 7 + 8
stuff, consolidate header). Before this commit the declarations for
RegisterPowerSettingNotification and UnregisterPowerSettingNotification
were guarded inside a #if (_WIN32_WINNT = 0x0600) section, but this
got changed in this commit to #if _WIN32_WINNT = 0x0502. According to
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373196%
28v=vs.85%29.aspx these symbols are only available as of Windows Vista
so the original code (0x0600) looks like the good one to me.
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
attached 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch
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 can benefit from these changes as well?
Regards,
Erik van Pienbroek
Fedora MinGW SIG
From 8269507a53e48bd584db5fa6a8d174681800e893 Mon Sep 17 00:00:00 2001
From: Erik van Pienbroek epien...@fedoraproject.org
Date: Wed, 31 Dec 2014 18:44:01 +0100
Subject: [PATCH 21/25] Lower _WIN32_WINNT requirements for
{Un,}RegisterPowerSettingNotification
This got changed in master in commit b354505ea8a1b93558c7941db2d94a949b922ecd
Perhaps this change was done by accident as the MSDN documentation at
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373196%28v=vs.85%29.aspx
indicates that these functions are only available as of Windows Vista
---
mingw-w64-headers/include/winuser.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/winuser.h b/mingw-w64-headers/include/winuser.h
index 975b00d..0f1f8cd 100644
--- a/mingw-w64-headers
[Mingw-w64-public] Mass rebuild report for August 03 2014
This is a report for the 20140803 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which
have been applied since the previous mass rebuild.
During this mass rebuild the following toolchain was used:
* mingw-w64 git ec1ff7 20140730 trunk snapshot
* binutils 2.24
* gcc 4.9.1
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 previous mass rebuild: 2
Time needed to perform mass rebuild: 24 hours, 26 minutes, 42 seconds
Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20140602
Total packages: 198
Number of failed packages: 2
Number of succeeded packages: 196
===
The following packages were added since the previous rebuild:
mingw-gsm
mingw-libid3tag
===
The following packages FAILED to rebuild:
mingw-clucene-2.3.3.4-10
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: greghellings
Time to build: 2 minutes, 19 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-clucene-2.3.3.4-10
mingw-dbus-1.6.12-2
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: ivanromanov
Time to build: 2 minutes, 4 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-dbus-1.6.12-2
mingw-wpcap-4.1.final2-13
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: sailer
Time to build: 1 minute, 11 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-wpcap-4.1.final2-13
===
The following packages were updated since the previous rebuild:
mingw-boost-1.55.0-1.fc21
--
* Mon Jun 30 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 1.55.0-1
- update to 1.55.0
mingw-crossreport-201406-1.fc21
* 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 -
3.1.999-0.12.trunk.gitec1ff7.20140730
- Update to 20140730 snapshot (git rev ec1ff7)
- Fixes invalid value of the global variable in6addr_loopback (RHBZ #1124368)
- Fixes missing memmove_s symbol on Windows XP/Server 2003
mingw-gcc-4.9.1-3.fc21
---
* Wed Jul 30 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.9.1-3
- Use /usr/lib instead of %{_libdir} (like also is done in
the native gcc and cross-gcc packages)
* Mon Jul 28 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.9.1-2
- Really enable std::threads support
* Fri Jul 18 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.9.1-1
- Update to gcc 4.9.1
mingw-glib2-2.41.2-1.fc21
--
* Tue Jul 22 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.41.2-1
- Update to 2.41.2
* Sat Jun 14 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.41.0-3
- Prevent an invalid @CARBON_LIBS@ from appearing in the .pc files (GNOME BZ
#731657)
mingw-glibmm24-2.41.1-1.fc21
-
* Tue Jul 01 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 2.41.1-1
- update to 2.41.1
mingw-gnutls-3.3.5-1.fc21
--
* Tue Jul 01 2014 Michael Cronenworth m...@cchtml.com - 3.3.5-1
- Update to 3.3.5
* Mon May 26 2014 Michael Cronenworth m...@cchtml.com - 3.3.2-1
- Update to 3.3.2
mingw-gtk2-2.24.24-2.fc21
--
* Wed Jul 30 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.24.24-2
- Fix build failure on environments with older gtk-doc
* Tue Jul 22 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.24.24-1
- Update to 2.24.24
mingw-headers-3.1.999-0.12.trunk.gitec1ff7.20140730.fc21
-
* Wed Jul 30 2014 Erik van Pienbroek epien...@fedoraproject.org -
3.1.999-0.12.trunk.gitec1ff7.20140730
- Update to 20140730 snapshot (git rev ec1ff7)
mingw-libtasn1-4.0-1.fc21
--
* Tue Jul 01 2014 Michael Cronenworth m...@cchtml.com - 4.0-1
- Update to 4.0
mingw-llvm-3.0-9.fc21
--
* Wed Jul 23 2014 Yaakov Selkowitz yselk...@redhat.com - 3.0-9
- Do not strip during make install (#1106207)
mingw-opusfile-0.6-1.fc21
--
* Sat Jun 14 2014 David King amigad...@amigadave.com 0.6-1
- Update to 0.6
Re: [Mingw-w64-public] Mass rebuild report for August 03 2014
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 previous mass rebuild: 2 Time needed to perform mass rebuild: 24 hours, 26 minutes, 42 seconds We've reached the milestone of 200 mingw packages in Fedora! Congrats to everybody who has been involved in this project since its start in 2008! The following packages FAILED to rebuild: mingw-clucene-2.3.3.4-10 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 2 minutes, 19 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-clucene-2.3.3.4-10 In file included from /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/threads.cpp:9:0: /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/_threads.h:55:104: error: conflicting declaration of C function 'void* _beginthread(void (__attribute__((__stdcall__)) *)(void*), unsigned int, void*)' void* _beginthread( void( __stdcall *start_address )( void * ), unsigned stack_size, void *arglist ); /usr/i686-w64-mingw32/sys-root/mingw/include/process.h:29: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); Conflicting declaration of _beginthread. Can the mingw-w64 devs indicate which declaration is correct and whether the fix should be applied in mingw-w64 itself or in upstream clucene? mingw-dbus-1.6.12-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: ivanromanov Time to build: 2 minutes, 4 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-dbus-1.6.12-2 CCLD dbus-daemon.exe /usr/lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt This should already be resolved in the latest stable version of dbus mingw-wpcap-4.1.final2-13 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 1 minute, 11 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-wpcap-4.1.final2-13 In file included from ../libpcap/Win32/Include/inetprivate.h:37:0, from ../libpcap/Win32/Src/getnetbynm.c:22: ../libpcap/Win32/Include/net/netdb.h:62:24: fatal error: netinet/in.h: No such file or directory #include netinet/in.h No idea what triggered this, but netinet/in.h is not available on mingw-w64 and shouldn't be used when compiling for the Windows target. Regards, Erik van Pienbroek -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Use correct initializer for in6addr_loopback and in6addr_any
In commit b8e8160d a fix was applied to prevent compiler
warnings when using IN6ADDR_ANY_INIT or IN6ADDR_LOOPBACK_INIT:
https://bugzilla.redhat.com/show_bug.cgi?id=1067426
Apparently this change wasn't fully complete as it turned
out to break the contents of the global variable in6addr_loopback:
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 in6addr_loopback and in6addr_any
In commit b8e8160d a fix was applied to prevent compiler
warnings when using IN6ADDR_ANY_INIT or IN6ADDR_LOOPBACK_INIT:
https://bugzilla.redhat.com/show_bug.cgi?id=1067426
Apparently this change wasn't fully complete as it turned
out to break the contents of the global variable in6addr_loopback:
https://bugzilla.redhat.com/show_bug.cgi?id=1124368
---
mingw-w64-crt/libsrc/ws2_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/libsrc/ws2_32.c b/mingw-w64-crt/libsrc/ws2_32.c
index 9584f81..34d880c 100644
--- a/mingw-w64-crt/libsrc/ws2_32.c
+++ b/mingw-w64-crt/libsrc/ws2_32.c
@@ -2,5 +2,5 @@
#include ws2tcpip.h
/* IPv6 constants for use in structure assignments (RFC 2553). */
-const struct in6_addr in6addr_any = {{ IN6ADDR_ANY_INIT }};
-const struct in6_addr in6addr_loopback = {{ IN6ADDR_LOOPBACK_INIT }};
+const struct in6_addr in6addr_any = IN6ADDR_ANY_INIT;
+const struct in6_addr in6addr_loopback = IN6ADDR_LOOPBACK_INIT;
--
2.0.1
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mingw-w64 toolchain now available for RHEL7/CentOS7 (using EPEL)
Hi, Some days ago Red Hat Enterprise Linux 7 was released. I'm glad to announce that a large subset of all mingw packages which are in Fedora are now also available in EPEL7 (the community supported set of additional packages for RHEL7 and CentOS7). The mingw packages which are now available in EPEL7 are the most recent stable releases of the most popular packages. This includes the core packages of the GNOME 3.12 stack (up to and including webkitgtk) and the entire Qt 4.8.6 and 5.3 stacks. The toolchain itself consists of binutils 2.24, gcc 4.9 and mingw-w64 trunk git b8e816 (dated 20140530). To install these packages, just install RHEL7 (or CentOS7 once it becomes available) and enable EPEL7 by installing http://download.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm Afterwards the mingw packages can be installed in the exact same way as is done for regular Fedora environments. For those new to using mingw-w64 on Fedora or RHEL a tutorial can be found at https://fedoraproject.org/wiki/MinGW/Tutorial Here's the entire list of mingw packages which are currently available on EPEL7: mingw-SDL-1.2.15-3.el7 mingw-SDL_image-1.2.12-8.el7 mingw-SDL_mixer-1.2.12-3.el7 mingw-angleproject-0-0.9.svn2215.20130517.el7 mingw-atk-2.12.0-1.el7 mingw-binutils-2.24-1.el7 mingw-boost-1.54.0-1.el7 mingw-bzip2-1.0.6-3.el7 mingw-cairo-1.12.16-2.el7 mingw-crt-3.1.999-0.10.trunk.gitb8e816.20140530.el7 mingw-curl-7.37.0-1.el7 mingw-dbus-1.6.12-1.el7 mingw-enchant-1.6.0-8.el7 mingw-expat-2.1.0-4.el7 mingw-filesystem-99-4.el7 mingw-flac-1.3.0-2.el7 mingw-fontconfig-2.11.1-1.el7 mingw-freetype-2.5.3-1.el7 mingw-gcc-4.9.0-1.el7 mingw-gdb-7.7-1.el7 mingw-gdk-pixbuf-2.30.8-1.el7 mingw-gettext-0.18.3.2-1.el7 mingw-glib-networking-2.38.2-2.el7 mingw-glib2-2.40.0-3.el7 mingw-gmp-5.1.1-3.el7 mingw-gnutls-3.3.2-2.el7 mingw-gstreamer1-1.3.2-1.el7 mingw-gstreamer1-plugins-base-1.3.2-1.el7 mingw-gtk2-2.24.23-1.el7 mingw-gtk3-3.12.2-1.el7 mingw-harfbuzz-0.9.28-1.el7 mingw-headers-3.1.999-0.10.trunk.gitb8e816.20140530.el7 mingw-hunspell-1.3.2-9.el7 mingw-icu-50.1.2-3.el7 mingw-jasper-1.900.1-21.el7 mingw-libffi-3.0.13-4.el7 mingw-libgcrypt-1.6.1-1.el7 mingw-libgpg-error-1.12-1.el7 mingw-libidn-1.28-2.el7 mingw-libjpeg-turbo-1.3.1-2.el7 mingw-libogg-1.3.0-4.el7 mingw-libpng-1.6.10-1.el7 mingw-libsoup-2.46.0-1.el7 mingw-libssh2-1.4.3-1.el7 mingw-libtasn1-3.6-1.el7 mingw-libtiff-4.0.3-4.el7 mingw-libvorbis-1.3.4-1.el7 mingw-libwebp-0.2.1-2.el7 mingw-libxml2-2.9.1-3.el7 mingw-libxslt-1.1.28-2.el7 mingw-nettle-2.7.1-2.el7 mingw-openssl-1.0.1e-6.el7 mingw-p11-kit-0.20.2-3.el7 mingw-pango-1.36.3-1.el7 mingw-pcre-8.34-1.el7 mingw-pdcurses-3.4-14.el7 mingw-pixman-0.32.0-1.el7 mingw-pkg-config-0.28-2.el7 mingw-postgresql-9.3.4-2.el7 mingw-qt-4.8.6-3.el7 mingw-qt5-qt3d-5.0.0-0.12.git20140525.bdb98ba.el7 mingw-qt5-qtbase-5.3.0-2.el7 mingw-qt5-qtdeclarative-5.3.0-2.el7 mingw-qt5-qtgraphicaleffects-5.3.0-2.el7 mingw-qt5-qtimageformats-5.3.0-2.el7 mingw-qt5-qtlocation-5.3.0-2.el7 mingw-qt5-qtmultimedia-5.3.0-2.el7 mingw-qt5-qtquick1-5.3.0-2.el7 mingw-qt5-qtscript-5.3.0-2.el7 mingw-qt5-qtsensors-5.3.0-2.el7 mingw-qt5-qtsvg-5.3.0-2.el7 mingw-qt5-qtsystems-5.0.0-0.14.git20140323.3f65ffa.el7 mingw-qt5-qttools-5.3.0-3.el7 mingw-qt5-qttranslations-5.3.0-1.el7 mingw-qt5-qtwebkit-5.3.0-2.el7 mingw-readline-6.2-4.el7 mingw-sqlite-3.8.4.3-1.el7 mingw-tcl-8.5.15-2.el7 mingw-termcap-1.3.1-15.el7 mingw-w64-tools-3.1.999-0.3.trunk.git502c72.20140524.el7 mingw-webkitgtk-2.2.7-2.el7 mingw-webkitgtk3-2.2.7-2.el7 mingw-win-iconv-0.0.6-1.el7 mingw-winpthreads-3.1.999-0.5.trunk.git502c72.20140524.el7 mingw-winstorecompat-3.1.999-0.1.trunk.git502c72.20140524.el7 mingw-xz-5.1.2-3alpha.el7 mingw-zlib-1.2.8-2.el7 Is your favorite package missing from this list and you want to have it available in EPEL7? Then there are some options: If the package is already in Fedora: - If you're a regular user then you can file a bug at http://bugzilla.redhat.com against the Fedora package in question where you ask the package maintainer if they're interested in making the package available for EPEL7 - If you're the package maintainer of the package in question then use https://fedoraproject.org/wiki/EPEL/epel7/Requests to request an epel7 branch for your package If the package is not in Fedora yet and you're willing to maintain it: - Write a RPM .spec file which follows the guidelines at https://fedoraproject.org/wiki/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 Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data
[Mingw-w64-public] Mass rebuild report for June 02 2014
This is a report for the 20140602 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 git b8e816 20140530 trunk snapshot * binutils 2.24 * gcc 4.9.0 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20140602 Total packages: 198 Number of failed packages: 2 Number of succeeded packages: 196 Number of added packages since previous mass rebuild: 4 Time needed to perform mass rebuild: 23 hours, 15 minutes, 32 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20140403 Total packages: 194 Number of failed packages: 5 Number of succeeded packages: 189 === The following packages were added since the previous rebuild: mingw-opusfile mingw-physfs mingw-SDL2 mingw-taglib === The following packages FAILED to rebuild: mingw-qt5-qtwebkit-5.3.0-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 39 minutes, 13 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140608/mingw-qt5-qtwebkit-5.3.0-1 mingw-tcl-8.5.15-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: Time to build: 4 minutes, 31 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140608/mingw-tcl-8.5.15-1 === 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 --- * Sat May 24 2014 Erik van Pienbroek epien...@fedoraproject.org - 1.12.16-2 - Fix build against gcc 4.9 by disabling LTO Thanks to LRN for the hint mingw-crt-3.1.999-0.10.trunk.gitb8e816.20140530.fc21 - * Fri May 30 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.10.trunk.gitb8e8160.20140530 - Update to 20140530 snapshot (git rev b8e8160) * Sat May 24 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.9.trunk.git502c72.20140524 - Update to 20140524 snapshot (git rev 502c72) - Upstream has switched from SVN to Git mingw-curl-7.37.0-1.fc21 - * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 7.37.0-1 - Update to 7.37.0 - Fixes CVE-2014-0138 and CVE-2014-0139 (RHBZ #1080880) mingw-dbus-glib-0.102-1.fc21 - * Thu May 15 2014 Greg Hellings greg.helli...@gmail.com - 0.102-1 - Updated to new upstream version - Removed upstreamed patch mingw-fontconfig-2.11.1-1.fc21 --- * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.11.1-1 - Update to 2.11.1 mingw-freetype-2.5.3-1.fc21 * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.5.3-1 - Update to 2.5.3 mingw-gcc-4.9.0-1.fc21 --- * Wed Apr 23 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.9.0-1 - Update to gcc 4.9.0 * Sun Apr 13 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.9.0-0.1.rc1 - Update to gcc 4.9.0 RC1 mingw-gdk-pixbuf-2.30.8-1.fc21 --- * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.30.8-1 - Update to 2.30.8 mingw-glib2-2.41.0-1.fc21 -- * Sun Jun 01 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 2.41.0-1 - update to 2.41.0 * Thu May 15 2014 Richard W.M. Jones rjo...@redhat.com - 2.40.0-3 - Fix valgrind support (RHBZ#1095664, GNOME bug 730198). - Include stdint.h, required by valgrind.h only on Rawhide. mingw-glibmm24-2.41.0-1.fc21 - * Sun Jun 01 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 2.41.0-1 - update to 2.41.0 mingw-gmp-6.0.0-1.fc21 --- * Tue Apr 15 2014 Michael Cronenworth m...@cchtml.com - 6.0.0-1 - New upstream release. mingw-gnutls-3.3.2-1.fc21 -- * Thu Apr 17 2014 Michael Cronenworth m...@cchtml.com - 3.3.0-1 - Update to 3.3.0 mingw-gstreamer-plugins-base-0.10.36-5.fc21 * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 0.10.36-5 - Fix FTBFS against mingw-gcc 4.9 mingw-gstreamer1-1.3.2-1.fc21 -- * Thu May 29 2014 Erik van Pienbroek epien...@fedoraproject.org - 1.3.2-1 - Update to 1.3.2 mingw-gstreamer1-plugins-base-1.3.2-1.fc21
[Mingw-w64-public] [PATCH] Use correct initializer for IN6ADDR macros
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: Thu, 29 May 2014 15:06:20 +0200
Subject: [PATCH] Use correct initializer for IN6ADDR macros
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
---
mingw-w64-headers/include/ws2tcpip.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/ws2tcpip.h b/mingw-w64-headers/include/ws2tcpip.h
index a428312..5d6afb9 100644
--- a/mingw-w64-headers/include/ws2tcpip.h
+++ b/mingw-w64-headers/include/ws2tcpip.h
@@ -73,8 +73,8 @@ struct ip_msfilter {
#define SS_PORT(ssp) (((struct sockaddr_in*)(ssp))-sin_port)
-#define IN6ADDR_ANY_INIT { 0 }
-#define IN6ADDR_LOOPBACK_INIT { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 }
+#define IN6ADDR_ANY_INIT { { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 } } }
+#define IN6ADDR_LOOPBACK_INIT { { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 } } }
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
--
1.9.3
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for April 03 2014 (using gcc 4.9)
This is a report for the 20140403 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. In this iteration of the mass rebuild the latest gcc 4.9 snapshot was used. As the previous mass rebuild was done only a couple of days ago (using gcc 4.8) all new build failures which are mentioned in this report can be blamed on compatibility issues with gcc 4.9 or issues within gcc 4.9 itself During this mass rebuild the following toolchain was used: * mingw-w64 r6559 20140330 trunk snapshot * binutils 2.24 * gcc 4.9 20140330 snapshot (rev 208948) Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20140403 Total packages: 194 Number of failed packages: 5 Number of succeeded packages: 189 Number of added packages since previous mass rebuild: 0 Time needed to perform mass rebuild: 24 hours, 25 minutes, 42 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20140331 Total packages: 194 Number of failed packages: 1 Number of succeeded packages: 193 === The following packages FAILED to rebuild: mingw-cairo-1.12.16-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 3 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-cairo-1.12.16-1 mingw-gstreamer-plugins-base-0.10.36-4 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 2 minutes, 17 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-gstreamer-plugins-base-0.10.36-4 mingw-gstreamer1-plugins-base-1.2.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 1 minute, 52 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-gstreamer1-plugins-base-1.2.1-1 mingw-gtkmm30-3.8.1-3 Package owner: kalev Time to build: 1 minute, 32 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-gtkmm30-3.8.1-3 mingw-qt5-qtsystems-5.0.0-0.10.git20130911.5084080 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 2 minutes, Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-qt5-qtsystems-5.0.0-0.10.git20130911.5084080 === The following packages were updated since the previous rebuild: mingw-fftw-3.3.4-1.fc21 * Wed Apr 02 2014 Thomas 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 208948) mingw-glibmm24-2.39.92-1.fc21 -- * Wed Apr 02 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 2.39.92-1 - update to 2.39.92 mingw-openjpeg-1.5.1-8.fc21 * Wed Apr 02 2014 Sandro Mani manisan...@gmail.com - 1.5.1-8 - Fix CVE-2014-0158 (see rhbz#1082997) mingw-polyclipping-6.1.3a-1.fc21 - * Wed Apr 02 2014 Thomas Sailer t.sai...@alumni.ethz.ch - 6.1.3a-1 - update to 6.1.3a === The following packages were rebuilt successfully: mingw-GConf2-3.2.6-3 Time to build: 2 minutes, 12 seconds mingw-LibRaw-0.16.0-1 Time to build: 1 minute, 39 seconds mingw-OpenEXR-2.1.0-2 Time to build: 2 minutes, 48 seconds mingw-SDL-1.2.15-4 Time to build: 1 minute, 26 seconds mingw-SDL_image-1.2.12-10 Time to build: 58 seconds mingw-SDL_mixer-1.2.12-4 Time to build: 46 seconds mingw-angleproject-0-0.9.svn2215.20130517 Time to build: 2 minutes, mingw-antlr-2.7.7-12 Time to build: 1 minute, 14 seconds mingw-atk-2.12.0-1 Time to build: 1 minute, 5 seconds mingw-atkmm-2.22.7-3 Time to build: 1 minute, 11 seconds mingw-binutils-2.24-1 Time to build: 7 minutes, 48 seconds mingw-boost-1.54.0-1 Time to build: 39 minutes, 47 seconds mingw-bzip2-1.0.6-4 Time to build: 49 seconds mingw-c-ares-1.10.0-2 Time to build: 12 minutes, 30 seconds mingw-cairomm-1.10.0-10 Time to build: 1 minute, 6 seconds mingw-celt051-0.5.1.3-12 Time to build: 1 minute, 4 seconds mingw-clucene-2.3.3.4-9 Time
Re: [Mingw-w64-public] [PATCH] Add secapi wrapper for strerror_s
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 @ r6559 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Add secapi wrapper for strerror_s
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 Mar 2014 15:14:25 +0100 Subject: [PATCH] Add secapi wrapper for strerror_s --- mingw-w64-crt/Makefile.am | 1 + mingw-w64-crt/Makefile.in | 46 ++--- mingw-w64-crt/lib32/msvcrt.def.in | 2 +- mingw-w64-crt/lib64/msvcrt.def.in | 2 +- mingw-w64-crt/secapi/strerror_s.c | 54 +++ 5 files changed, 99 insertions(+), 6 deletions(-) create mode 100644 mingw-w64-crt/secapi/strerror_s.c diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 271d2e7..4937840 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -181,6 +181,7 @@ src_msvcrt=\ secapi/memcpy_s.c \ secapi/rand_s.c \ secapi/sprintf_s.c \ + secapi/strerror_s.c \ secapi/vsprintf_s.c \ secapi/wmemcpy_s.c diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in index 818610b..789b47d 100644 --- a/mingw-w64-crt/Makefile.in +++ b/mingw-w64-crt/Makefile.in @@ -1114,8 +1114,9 @@ am__lib32_libmsvcrt_a_SOURCES_DIST = misc/invalid_parameter_handler.c \ secapi/_waccess_s.c secapi/_wasctime_s.c secapi/_wctime32_s.c \ secapi/_wctime64_s.c secapi/_wstrtime_s.c secapi/_wmktemp_s.c \ secapi/_wstrdate_s.c secapi/asctime_s.c secapi/memcpy_s.c \ - secapi/rand_s.c secapi/sprintf_s.c secapi/vsprintf_s.c \ - secapi/wmemcpy_s.c misc/lc_locale_func.c lib32/msvcrt.def.in + secapi/rand_s.c secapi/sprintf_s.c secapi/strerror_s.c \ + secapi/vsprintf_s.c secapi/wmemcpy_s.c misc/lc_locale_func.c \ + lib32/msvcrt.def.in am__objects_20 = \ misc/lib32_libmsvcrt_a-invalid_parameter_handler.$(OBJEXT) \ misc/lib32_libmsvcrt_a-output_format.$(OBJEXT) \ @@ -1152,6 +1153,7 @@ am__objects_20 = \ secapi/lib32_libmsvcrt_a-memcpy_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-rand_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-sprintf_s.$(OBJEXT) \ + secapi/lib32_libmsvcrt_a-strerror_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-vsprintf_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-wmemcpy_s.$(OBJEXT) am__objects_21 = $(am__objects_20) \ @@ -2247,8 +2249,8 @@ am__lib64_libmsvcrt_a_SOURCES_DIST = misc/invalid_parameter_handler.c \ secapi/_waccess_s.c secapi/_wasctime_s.c secapi/_wctime32_s.c \ secapi/_wctime64_s.c secapi/_wstrtime_s.c secapi/_wmktemp_s.c \ secapi/_wstrdate_s.c secapi/asctime_s.c secapi/memcpy_s.c \ - secapi/rand_s.c secapi/sprintf_s.c secapi/vsprintf_s.c \ - secapi/wmemcpy_s.c lib64/msvcrt.def.in + secapi/rand_s.c secapi/sprintf_s.c secapi/strerror_s.c \ + secapi/vsprintf_s.c secapi/wmemcpy_s.c lib64/msvcrt.def.in am__objects_52 = \ misc/lib64_libmsvcrt_a-invalid_parameter_handler.$(OBJEXT) \ misc/lib64_libmsvcrt_a-output_format.$(OBJEXT) \ @@ -2285,6 +2287,7 @@ am__objects_52 = \ secapi/lib64_libmsvcrt_a-memcpy_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-rand_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-sprintf_s.$(OBJEXT) \ + secapi/lib64_libmsvcrt_a-strerror_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-vsprintf_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-wmemcpy_s.$(OBJEXT) @LIB64_TRUE@@W32API_FALSE@am_lib64_libmsvcrt_a_OBJECTS = \ @@ -3908,6 +3911,7 @@ src_msvcrt = \ secapi/memcpy_s.c \ secapi/rand_s.c \ secapi/sprintf_s.c \ + secapi/strerror_s.c \ secapi/vsprintf_s.c \ secapi/wmemcpy_s.c @@ -7044,6 +7048,8 @@ secapi/lib32_libmsvcrt_a-rand_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-sprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) +secapi/lib32_libmsvcrt_a-strerror_s.$(OBJEXT): secapi/$(am__dirstamp) \ + secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-vsprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-wmemcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ @@ -8642,6 +8648,8 @@ secapi/lib64_libmsvcrt_a-rand_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-sprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) +secapi/lib64_libmsvcrt_a-strerror_s.$(OBJEXT): secapi/$(am__dirstamp) \ + secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-vsprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-wmemcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ @@ -11020,6 +11028,7 @@ distclean-compile: @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-memcpy_s.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-rand_s.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-sprintf_s.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-strerror_s.Po
Re: [Mingw-w64-public] Mass rebuild report for February 09 2014
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-5.1.1-3 mingw-qt5-qtlocation-5.2.1-1 mingw-qt5-qtquickcontrols-5.2.1-1 mingw-qt5-qtscript-5.2.1-1 mingw-qt5-qtwebkit-5.2.1-1 mingw-tesseract-3.02.02-4 mingw-webkitgtk-2.2.3-1 mingw-webkitgtk3-2.2.3-1 mingw-wine-gecko-2.24-1 All failed to build due to broken math.h https://sourceforge.net/p/mingw-w64/bugs/379/ mingw-gstreamer-0.10.36-5 This one is odd and probably not mingw related: CC libgstparse_la-grammar.tab.lo grammar.tab.c: In function 'priv_gst_parse_yyparse': grammar.tab.c:1819:7: error: too few arguments to function 'priv_gst_parse_yylex' if (yychar == YYEMPTY) ^ ../../../gst/parse/grammar.y:39:5: note: declared here int priv_gst_parse_yylex (void * yylval_param , yyscan_t yyscanner); ^ My first guess would be a change in behavior of the flex or bison tools mingw-qt5-qtactiveqt-5.2.1-1 mingw-qt5-qtxmlpatterns-5.2.1-1 These probably fail because mingw-qt5-qtbase 5.2.1 couldn't be built Regards, Erik -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for February 09 2014
the previous mass rebuild ** Package owner: epienbro Time to build: 1 minute, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-qt5-qtquickcontrols-5.2.1-1 mingw-qt5-qtscript-5.2.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 1 minute, 4 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-qt5-qtscript-5.2.1-1 mingw-qt5-qtwebkit-5.2.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 1 minute, 44 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-qt5-qtwebkit-5.2.1-1 mingw-qt5-qtxmlpatterns-5.2.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 2 minutes, 40 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-qt5-qtxmlpatterns-5.2.1-1 mingw-tesseract-3.02.02-4 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: smani Time to build: 2 minutes, 7 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-tesseract-3.02.02-4 mingw-webkitgtk-2.2.3-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 3 minutes, 29 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-webkitgtk-2.2.3-1 mingw-webkitgtk3-2.2.3-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 3 minutes, 32 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-webkitgtk3-2.2.3-1 mingw-wine-gecko-2.24-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: awjb Time to build: 3 minutes, 4 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140209/mingw-wine-gecko-2.24-1 === The following packages were updated since the previous rebuild: mingw-angleproject-0-0.9.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 the libraries are built with debugging symbols - Rebuild against latest mingw-w64 (fixes Windows XP compatibility, RHBZ #1054481) * Fri Jan 24 2014 Erik van Pienbroek epien...@fedoraproject.org - 0-0.8.svn2215.20130517 - Rebuilt against latest mingw-w64 to fix Windows XP compatibility (RHBZ #1054481) mingw-binutils-2.24-1.fc21 --- * Sat Jan 11 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.24-1 - Update to 2.24 mingw-crt-3.1.999-0.4.trunk.r6475.20140208.fc21 * Sat Feb 08 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.4.trunk.r6475.20140208 - Update to r6475 (20140208 snapshot) * Sun Jan 26 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.3.trunk.r6469.20140126 - Update to r6469 (20140126 snapshot) - Fixes missing sprintf_s issue on Windows XP/Server 2003 (RHBZ #1054481) * Fri Jan 24 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.2.trunk.r6460.20140124 - Update to r6460 (20140124 snapshot) - Fixes missing vsprintf_s issue on Windows XP/Server 2003 (RHBZ #1054481) * Thu Jan 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.999-0.1.trunk.r6432.20140104 - Bump version to keep working upgrade path mingw-filesystem-99-4.fc21 --- * Sat Feb 08 2014 Erik van Pienbroek epien...@fedoraproject.org - 99-4 - Place the RPM macros in /usr/lib/rpm/macros.d when using a modern RPM mingw-gdb-7.7-1.fc21 - * Fri Feb 07 2014 Kalev Lember kalevlem...@gmail.com - 7.7-1 - Update to 7.7 mingw-glib2-2.39.4-1.fc21 -- * Sat Feb 08 2014 Erik van Pienbroek epien...@fedoraproject.org - 2.39.4-1 - Update to 2.39.4 mingw-gnutls-3.2.8-1.fc21 -- * Sun Jan 26 2014 Michael Cronenworth m...@cchtml.com - 3.2.8-1 - Update to 3.2.8 - Drop iconv patch, upstream has dropped gnulib - Drop cli patch, now upstream mingw-harfbuzz-0.9.25-1.fc21 - * Sat Jan 25 2014 Erik van Pienbroek epien...@fedoraproject.org - 0.9.25-1 - Update to 0.9.25 mingw-headers-3.1.999-0.4.trunk.r6475.20140208.fc21
[Mingw-w64-public] [PATCH] Add secapi wrapper for sprintf_s
Hey, Here's a patch which implements a secapi wrapper for the sprintf_s symbol. It's needed to fix Windows XP compatibility in Qt5/ANGLE as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1057983 Okay to apply? Regards, Erik From dca6ecb46f9b3f2d5652bf27208ac4ecdae1a652 Mon Sep 17 00: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/msvcrt.def.in | 2 +- mingw-w64-crt/lib64/msvcrt.def.in | 2 +- mingw-w64-crt/secapi/sprintf_s.c | 21 ++ 5 files changed, 65 insertions(+), 6 deletions(-) create mode 100644 mingw-w64-crt/secapi/sprintf_s.c diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index ea384ac..bdca4fa 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -180,6 +180,7 @@ src_msvcrt=\ secapi/asctime_s.c \ secapi/memcpy_s.c \ secapi/rand_s.c \ + secapi/sprintf_s.c \ secapi/vsprintf_s.c \ secapi/wmemcpy_s.c diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in index 6669467..4c0c1cb 100644 --- a/mingw-w64-crt/Makefile.in +++ b/mingw-w64-crt/Makefile.in @@ -1114,8 +1114,8 @@ am__lib32_libmsvcrt_a_SOURCES_DIST = misc/invalid_parameter_handler.c \ secapi/_waccess_s.c secapi/_wasctime_s.c secapi/_wctime32_s.c \ secapi/_wctime64_s.c secapi/_wstrtime_s.c secapi/_wmktemp_s.c \ secapi/_wstrdate_s.c secapi/asctime_s.c secapi/memcpy_s.c \ - secapi/rand_s.c secapi/vsprintf_s.c secapi/wmemcpy_s.c \ - misc/lc_locale_func.c lib32/msvcrt.def.in + secapi/rand_s.c secapi/sprintf_s.c secapi/vsprintf_s.c \ + secapi/wmemcpy_s.c misc/lc_locale_func.c lib32/msvcrt.def.in am__objects_20 = \ misc/lib32_libmsvcrt_a-invalid_parameter_handler.$(OBJEXT) \ misc/lib32_libmsvcrt_a-output_format.$(OBJEXT) \ @@ -1151,6 +1151,7 @@ am__objects_20 = \ secapi/lib32_libmsvcrt_a-asctime_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-memcpy_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-rand_s.$(OBJEXT) \ + secapi/lib32_libmsvcrt_a-sprintf_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-vsprintf_s.$(OBJEXT) \ secapi/lib32_libmsvcrt_a-wmemcpy_s.$(OBJEXT) am__objects_21 = $(am__objects_20) \ @@ -2246,8 +2247,8 @@ am__lib64_libmsvcrt_a_SOURCES_DIST = misc/invalid_parameter_handler.c \ secapi/_waccess_s.c secapi/_wasctime_s.c secapi/_wctime32_s.c \ secapi/_wctime64_s.c secapi/_wstrtime_s.c secapi/_wmktemp_s.c \ secapi/_wstrdate_s.c secapi/asctime_s.c secapi/memcpy_s.c \ - secapi/rand_s.c secapi/vsprintf_s.c secapi/wmemcpy_s.c \ - lib64/msvcrt.def.in + secapi/rand_s.c secapi/sprintf_s.c secapi/vsprintf_s.c \ + secapi/wmemcpy_s.c lib64/msvcrt.def.in am__objects_52 = \ misc/lib64_libmsvcrt_a-invalid_parameter_handler.$(OBJEXT) \ misc/lib64_libmsvcrt_a-output_format.$(OBJEXT) \ @@ -2283,6 +2284,7 @@ am__objects_52 = \ secapi/lib64_libmsvcrt_a-asctime_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-memcpy_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-rand_s.$(OBJEXT) \ + secapi/lib64_libmsvcrt_a-sprintf_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-vsprintf_s.$(OBJEXT) \ secapi/lib64_libmsvcrt_a-wmemcpy_s.$(OBJEXT) @LIB64_TRUE@@W32API_FALSE@am_lib64_libmsvcrt_a_OBJECTS = \ @@ -3905,6 +3907,7 @@ src_msvcrt = \ secapi/asctime_s.c \ secapi/memcpy_s.c \ secapi/rand_s.c \ + secapi/sprintf_s.c \ secapi/vsprintf_s.c \ secapi/wmemcpy_s.c @@ -7039,6 +7042,8 @@ secapi/lib32_libmsvcrt_a-memcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-rand_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) +secapi/lib32_libmsvcrt_a-sprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ + secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-vsprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib32_libmsvcrt_a-wmemcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ @@ -8635,6 +8640,8 @@ secapi/lib64_libmsvcrt_a-memcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-rand_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) +secapi/lib64_libmsvcrt_a-sprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ + secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-vsprintf_s.$(OBJEXT): secapi/$(am__dirstamp) \ secapi/$(DEPDIR)/$(am__dirstamp) secapi/lib64_libmsvcrt_a-wmemcpy_s.$(OBJEXT): secapi/$(am__dirstamp) \ @@ -11012,6 +11019,7 @@ distclean-compile: @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-asctime_s.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-memcpy_s.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-rand_s.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@secapi/$(DEPDIR)/lib32_libmsvcrt_a-sprintf_s.Po@am__quote@ @AMDEP_TRUE
Re: [Mingw-w64-public] [PATCH] Add secapi wrapper for sprintf_s
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 a secapi wrapper for the sprintf_s symbol. It's needed to fix Windows XP compatibility in Qt5/ANGLE as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1057983 Okay to apply? Regards, Erik -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Two secapi fixes
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 users tried to run a Qt5 based application on Windows XP and Windows Server 2003, but stumbled across a fatal error indicating that the symbol vsprintf_s isn't available in msvcrt.dll [1]. After searching I've found out that the msvcrt.def.in still contains a reference to vsprintf_s even though there's a wrapper implementation of this symbol in mingw-w64-crt/secapi/vsprintf_s.c so it shouldn't be mentioned in the msvcrt.def.in file any more. After testing some more (see testcase at [2]) I also discovered some other issues with the secapi wrappers. 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/ -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Two secapi fixes
Hi, One of our users tried to run a Qt5 based application on Windows XP and Windows Server 2003, but stumbled across a fatal error indicating that the symbol vsprintf_s isn't available in msvcrt.dll [1]. After searching I've found out that the msvcrt.def.in still contains a reference to vsprintf_s even though there's a wrapper implementation of this symbol in mingw-w64-crt/secapi/vsprintf_s.c so it shouldn't be mentioned in the msvcrt.def.in file any more. After testing some more (see testcase at [2]) I also discovered some other issues with the secapi wrappers. 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 Pienbroek epien...@fedoraproject.org Date: Sun, 19 Jan 2014 17:11:40 +0100 Subject: [PATCH 1/2] Add _gmtime32 and _localtime32 to lib64/msvcrt.def These symbols are required by the secapi wrappers _gmtime32_s and _localtime32_s --- mingw-w64-crt/lib64/msvcrt.def.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-w64-crt/lib64/msvcrt.def.in b/mingw-w64-crt/lib64/msvcrt.def.in index ed81eff..a0d3647 100644 --- a/mingw-w64-crt/lib64/msvcrt.def.in +++ b/mingw-w64-crt/lib64/msvcrt.def.in @@ -356,6 +356,7 @@ _getw _getwch _getwche _getws +_gmtime32 ; _gmtime32_s replaced by emu _gmtime64 ; _gmtime64_s replaced by emu @@ -471,6 +472,7 @@ _lfind _loaddll _lfind_s _local_unwind +_localtime32 ; _localtime32_s replaced by emu _localtime64 ; _localtime64_s replaced by emu -- 1.8.4.2 From 2dac1e1583fa2d0f142a048e275845e829883777 Mon Sep 17 00:00:00 2001 From: Erik van Pienbroek epien...@fedoraproject.org Date: Sun, 19 Jan 2014 17:28:12 +0100 Subject: [PATCH 2/2] Remove rand_s and vsprintf_s from msvcrt.def.in These symbols are implemented in the secapi wrappers so they shouldn't be part of the msvcrt.def.in files any more --- mingw-w64-crt/lib32/msvcrt.def.in | 2 +- mingw-w64-crt/lib64/msvcrt.def.in | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mingw-w64-crt/lib32/msvcrt.def.in b/mingw-w64-crt/lib32/msvcrt.def.in index 6c2c3cf..3455447 100644 --- a/mingw-w64-crt/lib32/msvcrt.def.in +++ b/mingw-w64-crt/lib32/msvcrt.def.in @@ -1218,7 +1218,7 @@ vsnprintf == _vsnprintf snprintf == _snprintf snwprintf == _snwprintf vsnwprintf == _vsnwprintf -vsprintf_s +; vsprintf_s replaced by emu vswprintf_s vwprintf_s wcrtomb_s diff --git a/mingw-w64-crt/lib64/msvcrt.def.in b/mingw-w64-crt/lib64/msvcrt.def.in index a0d3647..ceff01e 100644 --- a/mingw-w64-crt/lib64/msvcrt.def.in +++ b/mingw-w64-crt/lib64/msvcrt.def.in @@ -1160,7 +1160,7 @@ qsort qsort_s raise rand -rand_s +; rand_s replaced by emu realloc remove rename @@ -1239,7 +1239,7 @@ vprintf_s vsnprintf == _vsnprintf snprintf == _snprintf vsprintf -vsprintf_s +; vsprintf_s replaced by emu vswprintf vswprintf_s vwprintf -- 1.8.4.2 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for January 11 2014
This is a report for the 20140111 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which
have been applied since the previous mass rebuild.
During this mass rebuild the following toolchain was used:
* mingw-w64 3.1.0
* binutils 2.23.52.0.1
* gcc 4.8.2
Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20140111
Total packages: 182
Number of failed packages: 1
Number of succeeded packages: 181
Number of added packages since previous mass rebuild: 0
Time needed to perform mass rebuild: 42 hours, 4 minutes, 25 seconds
Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20131204
Total packages: 182
Number of failed packages: 0
Number of succeeded packages: 182
===
The following packages FAILED to rebuild:
mingw-libgsf-1.14.28-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: greghellings
Time to build: 3 minutes, 16 seconds
Build logs:
http://build1.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...@fedoraproject.org - 2.11.3-1
- Update to 2.11.3
- Export the symbol atk_object_get_object_locale (required by webkitgtk)
mingw-crt-3.1.0-1.fc19
---
* Thu Jan 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.0-1
- Update to 3.1.0
mingw-gcc-4.8.2-2.fc19
---
* Fri Jan 10 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.8.2-2
- Dropped xmmintrin patch as the issue is resolved in mingw-w64 3.1.0
mingw-glib2-2.39.2-1.fc19
--
* Tue Dec 17 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.39.2-1
- Update to 2.39.2
mingw-gmp-5.1.3-1.fc19
---
* Tue Jan 07 2014 Michael Cronenworth m...@cchtml.com - 5.1.3-1
- New upstream release.
mingw-gstreamer1-1.2.1-1.fc19
--
* Wed Dec 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.2.1-1
- Update to 1.2.1
mingw-gstreamer1-plugins-base-1.2.1-1.fc19
---
* Wed Dec 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.2.1-1
- Update to 1.2.1
mingw-headers-3.1.0-1.fc19
---
* Thu Jan 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.0-1
- Update to 3.1.0
mingw-libzip-0.11.2-1.fc19
---
* Thu Dec 19 2013 Sandro Mani manisan...@gmail.com - 0.11.2-1
- Update to 0.11.2
mingw-poppler-0.24.5-1.fc19
* Fri Jan 03 2014 Sandro Mani manisan...@gmail.com - 0.24.5-1
- Update to 0.24.5, fixes #1048203
mingw-postgresql-9.3.2-1.fc19
--
* Tue Jan 07 2014 Michael Cronenworth m...@cchtml.com - 9.3.2-1
- New upstream release.
mingw-qt5-qt3d-5.0.0-0.9.git20130923.7433868.fc19
--
* Wed Jan 08 2014 Erik van Pienbroek epien...@fedoraproject.org -
5.0.0-0.9.git20130923.7433868
- Dropped manual rename of import libraries
* Sun Jan 05 2014 Erik van Pienbroek epien...@fedoraproject.org -
5.0.0-0.8.git20130923.7433868
- Update to 20130923 snapshot (rev 7433868)
This is the last Qt 5.2 based revision
mingw-qt5-qtactiveqt-5.2.0-2.fc19
--
* Fri Jan 10 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-2
- Added license files
* Mon Jan 06 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-1
- Update to 5.2.0
mingw-qt5-qtbase-5.2.0-3.fc19
--
* Mon Jan 06 2014 Erik van Pienbroek epein...@fedoraproject.org - 5.2.0-3
- Split the cmake patch and moved half of its contents to the 'implib dll'
patch and the other to the 'use external angle' patch as those are more
proper locations
* Sun Jan 05 2014 Yaakov Selkowitz yselkow...@users.sourceforge.net - 5.2.0-2
- Fix qmake to use .dll.a extension for implibs (avoids renaming hacks in
all mingw-qt5-* packages)
- Force usage of system zlib in Qt5Bootstrap
- Install shared libQt5BootstrapDBus for qdbuscpp2xml and qdbusxml2cpp
- Fix QMAKE_LIBS_NETWORK for static linkage
- Closes RHBZ #1048677
* Sun Jan 05 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-1
- Update to 5.2.0
- Use the generic win32-g++ mkspecs profile instead of win32-g++-cross
and win32-g++-cross-x64 (as is preferred by upstream)
- Add support for qtchooser
- Moved the native tools to /usr/$target/bin/qt5 (qtchooser requires the
tools to be in an unique folder with their original file names)
All symlinks in %{_bindir} are updated to reflect this as well
- Prevent invalid
[Mingw-w64-public] Mass rebuild report for December 04 2013
This is a report for the 20131204 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 r6388 20131129 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.2 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20131204 Total packages: 182 Number of failed packages: 0 Number of succeeded packages: 182 Number of added packages since previous mass rebuild: 6 Time needed to perform mass rebuild: 38 hours, 39 minutes, 57 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130917 Total packages: 176 Number of failed packages: 2 Number of succeeded packages: 174 === The following packages were added since the previous rebuild: mingw-hidapi mingw-log4c mingw-mpfr mingw-qt5-qtquickcontrols mingw-qt5-qtserialport mingw-qt5-qtwinextras === 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 - 2.11.2-1 - Update to 2.11.2 * Tue Sep 24 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.10.0-1 - Update to 2.10.0 mingw-clucene-2.3.3.4-9.fc19 - * Mon Oct 07 2013 Greg Hellings greg.helli...@gmail.com 2.3.3.4-9 - Forced rebuild for library compatibility mingw-crt-3.0.999-0.2.trunk.r6388.20131129.fc19 * Fri Nov 29 2013 Erik van Pienbroek epien...@fedoraproject.org - 3.0.999-0.2.trunk.r6388.20131129 - Update to r6388 (20131129 snapshot) * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 3.0.999-0.1.trunk.r6379.20131120 - Update to r6379 (20131120 snapshot) * Fri Sep 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 3.0.0-1 - Update to 3.0.0 mingw-curl-7.33.0-1.fc19 - * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 7.33.0-1 - Update to 7.33.0 - Fixes CVE-2013-4545, RHBZ #1031429 mingw-fontconfig-2.11.0-1.fc19 --- * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.11.0-1 - Update to 2.11.0 mingw-gcc-4.8.2-1.fc19 --- * Sat Oct 19 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.8.2-1 - Update to 4.8.2 - Build with C++11 std::thread support (F21+ only) * Fri Sep 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.8.1-4 - Rebuild against winpthreads mingw-giflib-5.0.5-1.fc19 -- * Mon Sep 30 2013 Sandro Mani manisan...@gmail.com - 5.0.5-1 - Update to 5.0.5 mingw-glib-networking-2.38.2-1.fc19 * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.38.2-1 - Update to 2.38.2 mingw-glib2-2.39.1-1.fc19 -- * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.39.1-1 - Update to 2.39.1 * Wed Nov 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.38.2-1 - Update to 2.38.2 * Tue Sep 24 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.38.0-1 - Update to 2.38.0 mingw-glibmm24-2.38.1-1.fc19 - * Tue Dec 03 2013 Thomas Sailer t.sai...@alumni.ethz.ch - 2.38.1-1 - update to 2.38.1 mingw-gmp-5.1.2-1.fc19 --- * Sun Sep 22 2013 Michael Cronenworth m...@cchtml.com - 5.1.2-1 - New upstream release. mingw-gnutls-3.1.16-1.fc19 --- * Thu Nov 07 2013 Michael Cronenworth m...@cchtml.com - 3.1.16-1 - Update to 3.1.16 * Tue Oct 29 2013 Michael Cronenworth m...@cchtml.com - 3.1.15-1 - Update to 3.1.15 - Enable ECC NIST Suite B curves * Sun Sep 22 2013 Michael Cronenworth m...@cchtml.com - 3.1.13-1 - Update to 3.1.13 mingw-gsl-1.16-1.fc19 -- * Fri Oct 04 2013 Alexey Kurov nuc...@fedoraproject.org - 1.16-1 - GSL 1.16 mingw-gstreamer-plugins-bad-free-0.10.23-10.fc19 - * Fri Sep 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 0.10.23-10 - Rebuild against winpthreads mingw-gtk-vnc-0.5.3-1.fc19 --- * Wed Sep 18 2013 Daniel P. Berrange berra...@redhat.com - 0.5.3-1 - Update to 0.5.3 release mingw-gtk2-2.24.22-1.fc19 -- * Sun Oct 13 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.24.22-1 - Update to 2.24.22 * Tue Sep 24 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.24.21-1 - Update to 2.24.21 mingw-gtk3-3.11.2-1.fc19 - * Wed Nov 20 2013 Erik van Pienbroek epien
Re: [Mingw-w64-public] MinGW-w64 v3.0.1
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 tagged it in svn some days ago, but I can't find tarballs or an announcement for it okt 01 00:22:59 jon_y epienbroek: the changes are just in _mingw_mac.h okt 01 00:23:17 jon_y changed from alpha to stable okt 01 00:24:26 jon_y epienbroek: I mean it is hardly release material okt 01 08:24:34 epienbroekjon_y, I understand..but then why are you tagging it, but not releasing it? this will confuse users..especially when the first 3.0.x update will be released later on okt 01 11:19:14 jon_y epienbroek: Kai wanted it tagged, but I was hesitant to rereleast 3.0.1 okt 01 11:19:23 jon_y *3.0.0 okt 01 11:19:35 jon_y so instead of retagging, I made 3.0.1 I guess that mingw-w64 3.0.1 will never be released and the first upcoming mingw-w64 v3 release will be marked as version 3.1.0 (as can be observed in r6321). Regards, Erik -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for September 17 2013
This is a report for the 20130917 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 r6284 20130914 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.1 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130917 Total packages: 176 Number of failed packages: 2 Number of succeeded packages: 174 Number of added packages since previous mass rebuild: 0 Time needed to perform mass rebuild: 37 hours, 48 minutes, 55 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130829 Total packages: 176 Number of failed packages: 6 Number of succeeded packages: 170 === The following packages FAILED to rebuild: mingw-tcl-8.5.14-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 2 minutes, 50 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130917/mingw-tcl-8.5.14-1 mingw-tk-8.5.13-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: roma Time to build: 1 minute, 38 seconds Build logs: http://build1.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...@fedoraproject.org - 2.9.4-1 - Update to 2.9.4 mingw-cairo-1.12.16-1.fc19 --- * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.12.16-1 - Update to 1.12.16 mingw-crt-2.0.999-0.38.trunk.r6284.20130914.fc19 - * Sat Sep 14 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.38.trunk.r6284.20130914 - Update to r6284 (20130914 snapshot) * Wed Sep 11 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.37.trunk.r6277.20130911 - Update to r6277 (20130911 snapshot) - Fixes undefined reference to `IID_ICustomDestinationList' - Fixes undefined reference to `IID_IFileOpenDialog' - Fixes undefined reference to `IID_IFileSaveDialog' * Mon Sep 09 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.36.trunk.r6258.20130909 - Update to r6258 (20130909 snapshot) * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.35.trunk.r6233.20130907 - Update to r6233 (20130907 snapshot) mingw-curl-7.32.0-1.fc19 - * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 7.32.0-1 - Update to 7.32.0 mingw-dbus-1.6.12-1.fc19 - * Tue Sep 03 2013 Ivan Romanov dr...@land.ru - 1.6.12-1 - A new upstream version * Thu Aug 29 2013 Ivan Romanov dr...@land.ru - 1.6.8-4 - Added patch to rename interface argument name (RHBZ #980278) mingw-dbus-glib-0.100.2-1.fc19 --- * Tue Sep 03 2013 Greg Hellings greg.helli...@gmail.com - 0.100.2-1 - Updated to new upstream version mingw-fontconfig-2.10.95-1.fc19 * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.10.95-1 - Update to 2.10.95 mingw-freetype-2.5.0.1-1.fc19 -- * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.5.0.1-1 - Update to 2.5.0.1 - Added BR: mingw32-libpng mingw64-libpng mingw-gettext-0.18.3.1-1.fc19 -- * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 0.18.3.1-1 - Update to 0.18.3.1 mingw-glib-networking-2.37.5-1.fc19 * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.37.5-1 - Update to 2.37.5 mingw-glib2-2.37.7-1.fc19 -- * Wed Sep 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.37.7-1 - Update to 2.37.7 mingw-glibmm24-2.37.6-1.fc19 - * Tue Sep 03 2013 Thomas Sailer t.sai...@alumni.ethz.ch - 2.37.6-1 - update to 2.37.6 mingw-gstreamer-0.10.36-5.fc19 --- * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 0.10.36-5 - Backported upstream commits which are needed to avoid FTBFS when winpthreads is available mingw-gstreamer1-1.1.4-1.fc19 -- * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.1.4-1 - Update to 1.1.4 - Fixes FTBFS when winpthreads is available * Sat Sep 07 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.0.10-1 - Update to 1.0.10 mingw-gtk3-3.9.14-1.fc19 - * Sat Sep 07 2013 Erik van Pienbroek epien
Re: [Mingw-w64-public] tcl fails to build due to conflicting implementation of EXCEPTION_REGISTRATION structure
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 nice if it could be fixed before release, but I can't make the decision on whether this should be considered a release blocker. That's something I leave up to you guys. Regards, Erik -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] tcl fails to build due to conflicting implementation of EXCEPTION_REGISTRATION structure
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 applied a workaround for the issue: http://pkgs.fedoraproject.org/cgit/mingw-tcl.git/commit/?id=46cbdbf110bc15ba57b6f90b6200f23d7ab6ac91 Regards, Erik -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] tcl fails to build due to conflicting implementation of EXCEPTION_REGISTRATION structure
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 -I..
-pipe -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\
-DSTDC_HEADERS=1 -DTCL_CFGVAL_ENCODING=\cp1252\ -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NO_SEH=1
-DHAVE_CAST_TO_UNION=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNDEBUG=1
-DTCL_CFG_OPTIMIZED=1 -DBUILD_tcl ../tclWin32Dll.c -o tclWin32Dll.o
../tclWin32Dll.c:63:3: error: conflicting types for
'EXCEPTION_REGISTRATION'
} EXCEPTION_REGISTRATION;
^
In file included
from /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:146:0,
from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8,
from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69,
from ../tclWinPort.h:23,
from ../../generic/tclPort.h:21,
from ../../generic/tclInt.h:36,
from ../tclWinInt.h:15,
from ../tclWin32Dll.c:14:
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3554:43: note:
previous declaration of 'EXCEPTION_REGISTRATION' was here
typedef EXCEPTION_REGISTRATION_RECORD EXCEPTION_REGISTRATION;
^
make: *** [tclWin32Dll.o] Error 1
This one is caused by the fact that tcl contains its own implementation
of the EXCEPTION_REGISTRATION structure. I've applied a workaround to
the tcl code so that it uses the mingw-w64 implementation of this
structure, but apparently this introduces a new build failure:
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 -I..
-pipe -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\
-DSTDC_HEADERS=1 -DTCL_CFGVAL_ENCODING=\cp1252\ -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NO_SEH=1
-DHAVE_CAST_TO_UNION=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNDEBUG=1
-DTCL_CFG_OPTIMIZED=1 -DBUILD_tcl ../tclWin32Dll.c -o tclWin32Dll.o
../tclWin32Dll.c: In function 'TclWinCPUID':
../tclWin32Dll.c:1170:26: error: 'EXCEPTION_REGISTRATION' has no member
named 'status'
status = registration.status;
^
make: *** [tclWin32Dll.o] Error 1
The mingw-w64 header excpt.h has this implementation for the
EXCEPTION_REGISTRATION structure:
typedef struct _EXCEPTION_REGISTRATION {
struct _EXCEPTION_REGISTRATION *prev;
EXCEPTION_DISPOSITION (*handler)(struct _EXCEPTION_RECORD*, void*,
struct _CONTEXT*, void*);
} EXCEPTION_REGISTRATION, *PEXCEPTION_REGISTRATION;
So the mingw-w64 EXCEPTION_REGISTRATION structure currently doesn't have
a field named 'status'.
The tcl of this structure is this:
typedef struct EXCEPTION_REGISTRATION {
struct EXCEPTION_REGISTRATION *link;
EXCEPTION_DISPOSITION (*handler)(
struct _EXCEPTION_RECORD*, void*, struct _CONTEXT*, void*);
void *ebp;
void *esp;
int status;
} EXCEPTION_REGISTRATION;
Any ideas on whether this should be fixed in mingw-w64?
Regards,
Erik
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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 tarballs which can be downloaded rather than pointing to a revision or commit because everyone will have for sure the exact same source up to the name of the tarball. How about we switch to a release model like the Wine folks do: every two weeks a new release is done of the trunk branch. Then once in in every while (say half a year) we can do a new stable release which is fully tested etc. These snapshot releases can then be properly identified using #define's so that downstream projects can identify which version of mingw-w64 is used. Having more frequent stable releases also helps all Linux distributions which have new release once every a half a year. Most of this can be automated using scripts and/or cronjobs so that one only has to manually sign-off and publish generated tarballs. Regards, Erik -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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 to developers and dedicated testers, but we can't expect regular users to keep up with this. So for regular users we need to have something that is between 'stable' and 'dev'. Therefore I think having a bi-weekly 'testing' release would be a nice compromise which can be realized with minimal effort. Regards, Erik -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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/wine-mono-0.0.8-3 I just tried to rebuild this one against the latest svn (r6258) and it still failed to build. Now it got a different error: ./.libs/libmonoruntime.a(libmonoruntime_la-assembly.o): In function `IDListContainerIsConsistent': /usr/x86_64-w64-mingw32/sys-root/mingw/include/shlobj.h:2654: multiple definition of `IDListContainerIsConsistent' pedump.o:/usr/x86_64-w64-mingw32/sys-root/mingw/include/shlobj.h:2654: first defined here I guess this needs a similar fix as was applied for shobjidl.h Done, should be fixed in r6259. Thanks for the fix. Unfortunately we're still not there yet with wine-mono (i686 target, sjlj exceptions): ../../mono/libgc/mark.c:410:7: error: unknown type name 'EXCEPTION_REGISTRATION' EXCEPTION_REGISTRATION ex_reg; ^ ../../mono/libgc/mark.c: In function 'GC_mark_some': ../../mono/libgc/mark.c:472:16: error: request for member 'handler' in something not a structure or union er.ex_reg.handler = mark_ex_handler; ^ ../../mono/libgc/mark.c:473:56: error: request for member 'prev' in something not a structure or union asm volatile (movl %%fs:0, %0 : =r (er.ex_reg.prev)); ^ ../../mono/libgc/mark.c:519:56: error: request for member 'prev' in something not a structure or union asm volatile (mov %0, %%fs:0 : : r (er.ex_reg.prev)); ^ ../../mono/libgc/mark.c:473:7: error: invalid lvalue in asm output 0 asm volatile (movl %%fs:0, %0 : =r (er.ex_reg.prev)); ^ Regards, Erik -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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 following packages failed to build: mingw-boost-1.54.0-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-boost-1.54.0-1 mingw-gtk3-3.9.14-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-gtk3-3.9.14-1 mingw-icu-50.1.2-2 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-icu-50.1.2-2 mingw-llvm-3.0-7 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-llvm-3.0-7 mingw-nsis-2.46-11 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-nsis-2.46-11 mingw-p11-kit-0.19.3-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-p11-kit-0.19.3-1 mingw-postgresql-9.2.4-4 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-postgresql-9.2.4-4 mingw-qt5-qtactiveqt-5.1.0-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-qt5-qtactiveqt-5.1.0-1 mingw-qt5-qtbase-5.1.1-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-qt5-qtbase-5.1.1-1 mingw-tcl-8.5.14-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-tcl-8.5.14-1 mingw-tk-8.5.13-3 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-tk-8.5.13-3 mingw-wine-gecko-2.21-3 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-wine-gecko-2.21-3 wine-mono-0.0.8-3 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/wine-mono-0.0.8-3 I don't have time at the moment to investigate these issues due to other priorities, but feel free to take a look at them. Regards, Erik -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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 failed to build. Now it got a different error: ./.libs/libmonoruntime.a(libmonoruntime_la-assembly.o): In function `IDListContainerIsConsistent': /usr/x86_64-w64-mingw32/sys-root/mingw/include/shlobj.h:2654: multiple definition of `IDListContainerIsConsistent' pedump.o:/usr/x86_64-w64-mingw32/sys-root/mingw/include/shlobj.h:2654: first defined here I guess this needs a similar fix as was applied for shobjidl.h Regards, Erik -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
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 off another test mass rebuild I would like to know whether there are still any winpthreads changes pending. Previous test mass rebuilds have shown that there are some areas where winpthreads isn't following the POSIX pthread specification and causes build failures. Do you still plan on fixing these in winpthreads or do you expect downstream software developers to adapt to the way winpthreads is implemented? Regards, Erik -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ 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 August 29 2013
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 in Fedora 20 once all build failures which are caused by it are resolved (if this takes too long the introduction of winpthreads in Fedora will have to be postponed until Fedora 21 which is scheduled for release in Q2 2014). The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet) mingw-libvirt-1.1.1-1 Package owner: berrange Time to build: 6 minutes, 39 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130829/mingw-libvirt-1.1.1-1 Also caused by winpthreads: CCLD libvirt.la ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientIOEventLoop': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1517: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientSetTLSSession': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:785: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:792: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:809: more undefined references to `pthread_sigmask' follow collect2: error: ld returned 1 exit status Hmm. The libvirt build for mingw explicitly wants to avoid pthread_*, and use native threading instead (at least we wanted to explicitly avoid the old pthreads-w32, and since we already have native thread support, we might as well use it instead of dragging in winpthreads). Probably a case of our configure checks not detecting the right situation once winpthreads are turned on. I'll see if we can get this fixed up for libvirt 1.1.2 (due real soon now), or if it will have to wait for 1.1.3 (a month out, but probably still in time to make it into F20). Is there an easy environment to set up (such as rawhide + a repo) for testing a mingw cross-build with winpthreads? Hi Eric, Some time ago I filed https://bugzilla.redhat.com/show_bug.cgi?id=969231 against the Fedora mingw-libvirt package for this issue. According to Daniel Berrange winpthreads isn't following the POSIX specifications as the symbol pthread_sigmask should be mentioned in signal.h while for winpthreads this symbol is currently only mentioned in pthread.h. Setting up an environment with Fedora MinGW + winpthreads requires some preparation (as I don't want to pollute rawhide yet). A recent rawhide environment should be enough as starting point. I just created some scratch builds which you can install directly with 'yum localinstall' to have a winpthreads-based mingw environment: http://koji.fedoraproject.org/koji/taskinfo?taskID=5871269 http://koji.fedoraproject.org/koji/taskinfo?taskID=5871279 Regards, Erik -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Build issues on trunk
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:
qt5-qtsystems:
In file included
from
/builddir/build/BUILD/qt-qtsystems/src/systeminfo/windows/qdeviceinfo_win.cpp:50:0:
/usr/i686-w64-mingw32/sys-root/mingw/include/vfw.h:908:3: error:
'interface' does not name a type
DECLARE_INTERFACE_(IAVIStream,IUnknown) {
^
In file included
from
/builddir/build/BUILD/qt-qtsystems/src/systeminfo/windows/qdeviceinfo_win.cpp:50:0:
/usr/i686-w64-mingw32/sys-root/mingw/include/vfw.h:925:11: error:
'IAVIStream' does not name a type
typedef IAVIStream *PAVISTREAM;
^
(and some more cascaded ones, to me the 'interface' one looks like the
primary cause)
qt5-qtbase:
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/src/corelib/io/qfilesystemengine_win.cpp:578:3:
error: conflicting declaration 'typedef struct _FILE_ID_128 FILE_ID_128'
} FILE_ID_128, *PFILE_ID_128;
^
In file included
from /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:146:0,
from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8,
from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69,
from
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/include/QtCore/../../src/corelib/global/qt_windows.h:71,
from
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/include/QtCore/qt_windows.h:1,
from /builddir/build/BUILD/qtbase-opensource-src-5.1.0/mkspecs/win32-g
++-cross/qplatformdefs.h:63,
from
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/src/corelib/io/qfilesystemmetadata_p.h:56,
from
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/src/corelib/io/qfilesystemengine_p.h:58,
from
/builddir/build/BUILD/qtbase-opensource-src-5.1.0/src/corelib/io/qfilesystemengine_win.cpp:42:
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3767:7: error:
'FILE_ID_128' has a previous declaration as 'typedef struct FILE_ID_128
FILE_ID_128'
} FILE_ID_128, *PFILE_ID_128;
^
This seems to be caused by the fact that this structure was only added
to mingw-w64 recently (r6115). As it was missing before, the qt folks
decided to manually implement it for mingw compilers and msvc = 1700.
Apparently the qt5-qtbase implementation of this structure differs from
the implementation done in mingw-w64. For comparison:
==
mingw-w64 winnt.h:
typedef struct FILE_ID_128 {
ULONGLONG LowPart;
ULONGLONG HighPart;
} FILE_ID_128, *PFILE_ID_128;
==
qt5-qtbase:
# if defined(Q_CC_MINGW) || (defined(Q_CC_MSVC) _MSC_VER 1700)
typedef struct _FILE_ID_128 {
BYTE Identifier[16];
} FILE_ID_128, *PFILE_ID_128;
typedef struct _FILE_ID_INFO {
ULONGLONG VolumeSerialNumber;
FILE_ID_128 FileId;
} FILE_ID_INFO, *PFILE_ID_INFO;
# endif // if defined (Q_CC_MINGW) || (defined(Q_CC_MSVC) _MSC_VER 1700))
==
The MSDN docs are a bit vague in this area. They only refer to a structure
called EXT_FILE_ID_128 instead of just FILE_ID_128:
http://msdn.microsoft.com/nl-nl/library/windows/desktop/hh802691%28v=vs.85%29.aspx
and
http://msdn.microsoft.com/nl-nl/library/windows/desktop/hh965605%28v=vs.85%29.aspx
Regards,
Erik
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Build issues on trunk
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= __attribute__((__stdcall__)) -DEXEHEAD -DWIN32_LEAN_AND_MEAN -D_WIN32_IE=0x0500 -DNSIS_COMPRESS_USE_BZIP2 -Ibuild/release/config Source/exehead/Ui.c In file included from Source/exehead/Ui.c:19:0: /usr/i686-w64-mingw32/sys-root/mingw/include/shellapi.h:191:16: error: conflicting types for 'PRINTEROP_FLAGS' typedef WORD PRINTEROP_FLAGS; ^ In file included from Source/exehead/Ui.c:18:0: /usr/i686-w64-mingw32/sys-root/mingw/include/shlobj.h:606:16: note: previous declaration of 'PRINTEROP_FLAGS' was here typedef UINT PRINTEROP_FLAGS; ^ === wine-gecko: In file included from ../../dist/include/nsWindowsDllInterceptor.h:9:0, from /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/base/AvailableMemoryTracker.cpp:25: /usr/i686-w64-mingw32/sys-root/mingw/include/winternl.h:913:27: error: conflicting declaration 'typedef THREADINFOCLASS THREAD_INFORMATION_CLASS' typedef THREADINFOCLASS THREAD_INFORMATION_CLASS, *PTHREAD_INFORMATION_CLASS; ^ In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:70:0, from ../../dist/include/nsWindowsDllInterceptor.h:8, from /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/base/AvailableMemoryTracker.cpp:25: /usr/i686-w64-mingw32/sys-root/mingw/include/winbase.h:1164:5: error: 'THREAD_INFORMATION_CLASS' has a previous declaration as 'typedef enum _THREAD_INFORMATION_CLASS THREAD_INFORMATION_CLASS' } THREAD_INFORMATION_CLASS; ^ === Could somebody take a look at these? Thanks! Erik -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Dependency on libgcc_s_sjlj-1.dll for i686 shared libraries when gcc 4.8 is used
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 with earlier versions of gcc. See [1] and the link to a gcc bug report given there. Short answer: this is intended. [1] http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/8096 Hi LRN, I noticed the other thread about this subject. We're glad to see that something in mingw-w64-crt was spotted which was accidentally pulling in the libgcc dependency. We've already been testing against the latest mingw-w64 (which contains the fix in question) and it does help with eliminating the libgcc dep in various situations (like zlib), but now we've found out that there are more situations which also pull in libgcc which we believe to be unintended. As this is a different root cause I decided to create a new thread instead of continuing in the existing one. The bugzilla ticket mentioned in that thread (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120) indeed sounds like the issue we're observing. Too bad that the bugzilla ticket is already closed as 'INVALID', but by reporting it on this mailing list I was hoping to give it some more exposure and hopefully also a proper fix or workaround Regards, Erik -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Usability improvement: add debug breaks to abort() calls
LRN schreef op do 08-08-2013 om 12:23 [+0400]: This is mostly a usability change. I, personally, really don't like when a program i'm debugging suddenly dies for no reason. Opinions? I would really welcome such a change. In the past we've already stumbled across 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=995059 Regards, Erik van Pienbroek -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] linking issue with postgresql and curl
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 issue about libgcc.dll file. Hey Kai, I've reproduced the issue Michael is talking about. When the testcase is opened in dependency walker it indicates that it has direct dependencies on libcurl-4.dll and libpq.dll (as expected). Initially everything looks as expected. However, when I try to execute the testcase using dependency walker then it shows that an additional dependency is introduced for a library named 'empty string'. The dependency walker console shows this output: == Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module. Starting profile on 8/10/2013 at 3:10:43 PM Operating System: Microsoft Windows XP Professional (64-bit), version 5.01.2600 Service Pack 3 Program Executable: z:\home\erik\LIBPQTEST.EXE Program Arguments: Starting Directory: Z:\home\erik\ Search Path: C:\windows\system32;C:\windows;C:\windows\system32\wbem Options Selected: Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable. Log DllMain calls for process attach and process detach messages. Hook the process to gather more detailed dependency information. Log LoadLibrary function calls. Log GetProcAddress function calls. Log debug output messages. Automatically open and profile child processes. Started LIBPQTEST.EXE (process 0x25) at address 0x0040. Cannot hook module. Error writing a breakpoint at the entrypoint return of KERNEL32.DLL. Entrypoint cannot be hooked. Access denied (5). Error reading KERNEL32.DLL's export table. Function call tracking may not work properly. Access denied (5). Loaded KERNEL32.DLL at address 0x7B81. Cannot hook module. Error reading the DOS header of NTDLL.DLL. Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of NTDLL.DLL. Entrypoint address cannot be determined. Access denied (5). Loaded NTDLL.DLL at address 0x7BC1. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7ECD. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7EC3. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x6CEC. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7EB1. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7EFF. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7E9C. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x7E98. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x6508. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x6300. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access denied (5). Error reading the PE headers of . Entrypoint address cannot be determined. Access denied (5). Loaded at address 0x6394. Cannot hook module. Error reading the DOS header of . Virtual size of module cannot be determined. Access
[Mingw-w64-public] Mass rebuild report for July 24 2013
This is a report for the 20130724 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. Unlike the previous mass rebuild this run was done against a mingw-w64 toolchain without winpthreads (thus the old pthreads-w32 implementation is used). Therefore the amount of failed builds is a bit less than the previous run. In the next mass rebuild, winpthreads will be part of the toolchain again During this mass rebuild the following toolchain was used: * mingw-w64 20130721 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.1 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130724 Total packages: 173 Number of failed packages: 3 Number of succeeded packages: 170 Number of added packages since previous mass rebuild: 1 Time needed to perform mass rebuild: 33 hours, 13 minutes, 2 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130715 Total packages: 173 Number of failed packages: 16 Number of succeeded packages: 157 === The following packages were added since the previous rebuild: mingw-postgresql === The following packages FAILED to rebuild: 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 mingw-libvirt-1.0.5-2 Package owner: berrange Time to build: 5 minutes, 12 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-libvirt-1.0.5-2 mingw-qt5-qtwebkit-5.1.0-2 Package owner: epienbro Time to build: 1 hour, 40 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-qt5-qtwebkit-5.1.0-2 === 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 - Fix FTBFS on recent mingw-w64 and also use intrinsics based versions of the Interlocked symbols which are better optimized mingw-crossreport-8-6.fc19 --- * Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 8-6 - Perl 5.18 rebuild mingw-crt-2.0.999-0.30.trunk.r5969.20130721.fc19 - * Sun Jul 21 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.30.trunk.r5969.20130721 - Update to r5969 (20130721 snapshot) - Fixes strnlen issue on Windows XP mingw-fontconfig-2.10.93-2.fc19 * Sun Jul 21 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.10.93-2 - Rebuild to avoid strnlen dependency which causes runtime issues on Windows XP mingw-headers-2.0.999-0.30.trunk.r5969.20130721.fc19 - * Sun Jul 21 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.30.trunk.r5969.20130721 - Update to r5969 (20130721 snapshot) - Resolves mingw-boost failure for the i686 target (regarding Interlocked* symbols) mingw-libgsf-1.14.27-1.fc19 * Wed Jul 17 2013 Greg Hellings greg.helli...@gmail.com - 1.14.27-1 - Updated to new upstream version mingw-nsiswrapper-10-2.fc19 * Wed Jul 17 2013 Petr Pisar ppi...@redhat.com - 10-2 - Perl 5.18 rebuild mingw-qt5-qt3d-5.0.0-0.5.git20130510.0158ce78.fc19 --- * Thu Jul 18 2013 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.5.git20130510.0158ce78 - Make sure the syncqt tool is run because we're using a git snapshot mingw-qt5-qtconnectivity-5.0.0-0.5.git20130510.8d6a8446.fc19 - * Thu Jul 18 2013 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.5.git20130510.8d6a8446 - Make sure the syncqt tool is run because we're using a git snapshot mingw-qt5-qtfeedback-5.0.0-0.5.git20130510.eb48acef.fc19 - * Thu Jul 18 2013 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.5.git20130510.eb48acef - Make sure the syncqt tool is run because we're using a git snapshot mingw-qt5-qtlocation-5.0.0-0.5.git20130510.f2840834.fc19 - * Thu Jul 18 2013 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.5.git20130510.f2840834 - Make sure the syncqt tool is run because we're using a git snapshot mingw-qt5-qtpim-5.0.0-0.5.git20130510.9352f485.fc19
Re: [Mingw-w64-public] Mass rebuild report for July 24 2013
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, package needs to be updated to support libpng 1.6 mingw-libvirt-1.0.5-2 Package owner: berrange Time to build: 5 minutes, 12 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-libvirt-1.0.5-2 This one was also already known. The issue is already fixed in upstream gnulib. The package maintainer needs to backport the specific commit manually or update its bundled gnulib copy mingw-qt5-qtwebkit-5.1.0-2 Package owner: epienbro Time to build: 1 hour, 40 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130724/mingw-qt5-qtwebkit-5.1.0-2 Here's a new one which I find rather odd. It fails with this error: == x86_64-w64-mingw32-g++ -c snip -o .obj/release-shared/InspectorAllInOne.o /builddir/build/BUILD/qtwebkit-opensource-src-5.1.0/Source/WebCore/inspector/InspectorAllInOne.cpp /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/as: /tmp/ccache/9/0/6e2e9b0c576e2ac1d280a709afe9d9-8861448.o.tmp.breda.vanpienbroek.nl.6559: too many sections (36836) /tmp/cc5P6BZt.s: Assembler messages: /tmp/cc5P6BZt.s: Fatal error: can't write /tmp/ccache/9/0/6e2e9b0c576e2ac1d280a709afe9d9-8861448.o.tmp.breda.vanpienbroek.nl.6559: File too big /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/as: /tmp/ccache/9/0/6e2e9b0c576e2ac1d280a709afe9d9-8861448.o.tmp.breda.vanpienbroek.nl.6559: too many sections (36836) /tmp/cc5P6BZt.s: Fatal error: can't close /tmp/ccache/9/0/6e2e9b0c576e2ac1d280a709afe9d9-8861448.o.tmp.breda.vanpienbroek.nl.6559: File too big make[3]: *** [.obj/release-shared/InspectorAllInOne.o] Error 1 == Anybody got a clue here what might be going wrong and what we can do to fix it? In the output there are references to ccache (which the Fedora mock build tool use by default), but the issue also happens when ccache is disabled. Regards, Erik van Pienbroek Fedora MinGW SIG -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
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 older mingw-w64 release, not checking version is better. If it doesn't, then yeah, something like that may be needed. All my tests were done against trunk snapshots (so major version 3). I could add such a conditional, but what benefit would it have? The mingw-w64 v1 branch also has an intrin.h with declarations for the Interlocked symbols, so the current patch should work just fine on the v1 branch. Regards, Erik -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
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 provide his opinion about the situation and perhaps get in contact with upstream boost devs to discuss this issue. Erik -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
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 of the mingw-boost package - Thomas Sailer - and asked him if he could provide his opinion about the situation and perhaps get in contact with upstream boost devs to discuss this issue. I've just got a response from Thomas. He has indicated that he doesn't really have a relationship with the upstream boost devs, but he's willing to try to get any patches upstreamed which we can come up with. 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. Regards, Erik -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
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 in question already contained an #include intrin.h, but it was only part of an #ifdef _MSC_VER section (which doesn't get triggered for mingw-w64). I've changed this #ifdef clause so that it also includes intrin.h when the mingw-w64 compiler is used. With this patch I've done the following build tests: using an old mingw-w64 snapshot (20121016): success! using a recent mingw-w64 snapshot (20130713, r5949): success! using a bleeding edge mingw-w64 snapshot (20130721, r5969): success! The qpid-cpp build failure is also resolved with this patch as well. Unless somebody objects I think this patch is good enough to be proposed upstream. Regards, Erik --- boost/detail/interlocked.hpp.interlocked 2012-12-11 15:42:26.0 +0100 +++ boost/detail/interlocked.hpp 2013-07-21 15:22:56.082346444 +0200 @@ -69,9 +69,9 @@ # define BOOST_INTERLOCKED_EXCHANGE_POINTER(dest,exchange) \ ((void*)BOOST_INTERLOCKED_EXCHANGE((long*)(dest),(long)(exchange))) -#elif defined( BOOST_MSVC ) || defined( BOOST_INTEL_WIN ) +#elif defined( BOOST_MSVC ) || defined( BOOST_INTEL_WIN ) || defined( __MINGW64_VERSION_MAJOR ) -#if defined( BOOST_MSVC ) BOOST_MSVC = 1600 +#if ( defined( BOOST_MSVC ) BOOST_MSVC = 1600 ) || defined( __MINGW64_VERSION_MAJOR ) #include intrin.h @@ -93,12 +93,16 @@ #endif +# if defined( BOOST_MSVC ) + # pragma intrinsic( _InterlockedIncrement ) # pragma intrinsic( _InterlockedDecrement ) # pragma intrinsic( _InterlockedCompareExchange ) # pragma intrinsic( _InterlockedExchange ) # pragma intrinsic( _InterlockedExchangeAdd ) +# endif + # if defined(_M_IA64) || defined(_M_AMD64) extern C void* __cdecl _InterlockedCompareExchangePointer( void* volatile *, void*, void* ); -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
dw schreef op za 20-07-2013 om 02:07 [-0700]: An argument could be made that we have broken backward compatibility and it's our responsibility to fix it. On the other hand, one could say they are using our library incorrectly (by not including any of our headers), and the fact that it worked at all was a fluke and inconsistent with the MSDN docs. I would say we have to mimic the MSVC behavior as close as possible. This bring us to the question whether boost can be compiled successfully for x86_64 using MSVC. If the upstream boost devs have added 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 end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?
dw schreef op za 20-07-2013 om 02:07 [-0700]: Boost could: 1) Use winbase.h (via windows.h) like the MSDN docs say they should. In fact, I wonder if defining BOOST_USE_WINDOWS_H would work. I just did some more testing. According to http://sligt.wordpress.com/2011/03/05/compiling-boost-thread-using-mingw64/ people are recommended to define BOOST_USE_WINDOWS_H when building boost using mingw-w64 for the x64 target. With this specific define set the boost package can indeed be compiled without issues (for both the x86 and x64 targets). However, there's a catch! The boost build system doesn't embed this specific define in its installed headers. It expects that all boost-using projects (like qpid-cpp) also have this BOOST_USE_WINDOWS_H define set otherwise it will also cause build failures there. So I guess that changes to our package build scripts alone aren'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 from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
Hi, We recently received some bug reports that executables compiled with mingw-w64 couldn't be executed on Windows XP environments. Users would get fatal error messages which indicate that the symbol strnlen couldn't be found in msvcrt.dll (which is correct for Windows XP). I've verified this with Dependency Walker and some binaries indeed were under the assumption that strnlen is part of msvcrt.dll. This is odd as the mingw-w64 crt contains a wrapper implementation for strnlen (in order to fix these Windows XP compatibility issues). So I investigated further and found out that strnlen is still being referenced in the msvcrt.def files. As other wrapped symbols are also commented out in msvcrt.def I got the impression that wrapped symbols should be removed from msvcrt.def. I did this for strnlen in my local test environment and it indeed caused the strnlen in msvcrt.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 epien...@fedoraproject.org Date: Thu, 18 Jul 2013 21:35:11 +0200 Subject: [PATCH] Remove reference to strnlen from msvcrt.def The symbol strnlen is missing from msvcrt.dll in Windows XP. Therefore a wrapper function was added to the crt in r3513 to fix compatibility with Windows XP, but the msvcrt.def file wasn't updated to reflect this. Therefore compiled binaries could still be under the assumption that the strnlen always is part of msvcrt.dll and cause runtime problems on Windows XP --- mingw-w64-crt/lib32/msvcrt.def.in | 2 +- mingw-w64-crt/lib64/msvcrt.def.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-crt/lib32/msvcrt.def.in b/mingw-w64-crt/lib32/msvcrt.def.in index ad8ec29..3fb17eb 100644 --- a/mingw-w64-crt/lib32/msvcrt.def.in +++ b/mingw-w64-crt/lib32/msvcrt.def.in @@ -1205,7 +1205,7 @@ strcpy_s strerror_s strncat_s strncpy_s -strnlen DATA ; msvcrt in XP and lower doesn't have this +; strnlen replaced by emu strtok_s swprintf_s swscanf_s diff --git a/mingw-w64-crt/lib64/msvcrt.def.in b/mingw-w64-crt/lib64/msvcrt.def.in index 14f6083..ed81eff 100644 --- a/mingw-w64-crt/lib64/msvcrt.def.in +++ b/mingw-w64-crt/lib64/msvcrt.def.in @@ -1198,7 +1198,7 @@ strncat_s strncmp strncpy strncpy_s -strnlen DATA ; msvcrt in XP and lower doesn't have this +; strnlen replaced by emu strpbrk strrchr strspn -- 1.8.3.1 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ 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 July 15 2013
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. The following packages FAILED to rebuild: mingw-boost-1.53.0-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-boost-1.53.0-1 In function `ZN5boost6detail17basic_timed_mutex7destroyEv': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/basic_timed_mutex.hpp:52: undefined reference to `_imp___InterlockedExchange@8' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `interlocked_bit_test_and_set': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/thread_primitives.hpp:408: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `ZN5boost6detail17basic_timed_mutex6unlockEv': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/basic_timed_mutex.hpp:220: undefined reference to `_imp___InterlockedExchangeAdd@8' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `interlocked_bit_test_and_set': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/thread_primitives.hpp:408: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `interlocked_read_acquire': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/interlocked_read.hpp:65: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `ZN5boost6detail17basic_timed_mutex25mark_waiting_and_try_lockERl': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/basic_timed_mutex.hpp:97: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `interlocked_read_acquire': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/interlocked_read.hpp:65: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o: In function `ZN5boost6detail17basic_timed_mutex26clear_waiting_and_try_lockERl': /builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/basic_timed_mutex.hpp:113: undefined reference to `_imp___InterlockedCompareExchange@12' serial/boost/bin.v2/libs/locale/build/gcc-mingw-4.8.1/release/debug-symbols-on/pch-off/target-os-windows/threading-multi/win32/lcid.o:/builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread/win32/basic_timed_mutex.hpp:243: more undefined references to `_imp___InterlockedCompareExchange@12' follow collect2: error: ld returned 1 exit status == This sounds like the recent mingw-w64 intrinsic changes.. mingw-cximage-600-9 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-cximage-600-9 /builddir/build/BUILD/mingw-cximage-600/build_win32/../CxImage/ximapng.cpp:52: undefined reference to `png_create_read_struct' /builddir/build/BUILD/mingw-cximage-600/build_win32/../CxImage/ximapng.cpp:56: undefined reference to `png_create_info_struct' /builddir/build/BUILD/mingw-cximage-600/build_win32/../CxImage/ximapng.cpp:73: undefined reference to `png_set_read_fn' == This package isn't compatible with libpng 1.6 yet. Needs to be reported and fixed upstream. mingw-gstreamer-0.10.36-3 mingw-gstreamer1-1.0.6-1 Old business here, winpthreads related. See earlier discussions mingw-libvirt-1.0.5-2 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-libvirt-1.0.5-2 Known issue which is already resolved in upstream gnulib mingw-qpid-cpp-0.14-7 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-qpid-cpp-0.14-7 CMakeFiles/qpidcommon.dir/objects.a(AsynchIO.obj): In function `interlocked_read_acquire': /usr/i686-w64-mingw32/sys-root/mingw/include/boost/thread/win32/interlocked_read.hpp:61: undefined reference to `_imp___InterlockedCompareExchange@12' CMakeFiles/qpidcommon.dir/objects.a(AsynchIO.obj): In function `ZN5boost6detail26basic_recursive_mutex_implINS0_17basic_timed_mutexEE4lockEv': /usr/i686-w64-mingw32/sys-root/mingw/include
Re: [Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
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 is successful with mingw-w64 r5915 (20130628), but with the mingw-w64 r5949 (20130713) the build fails for the x86_64-w64-mingw32 target with this error: x86_64-w64-mingw32-g++ -c -include .obj/release-static/qt_pch.h -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 --param=ssp-buffer-size=4 -fno-keep-inline-dllexport -O2 -Wall -frtti -fexceptions -mthreads -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQLIBRARYINFO_EPOCROOT -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3 -DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2 -DQT_HAVE_AVX -I'../../include' -I'../../include/QtCore' -I'.rcc/release-static' -I'tmp' -I'global' -I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/tools/shared' -I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/harfbuzz/src' -I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/md5' -I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/md4' -I'../../include/ActiveQt' -I'.moc/release-static' -I'.' -I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/mkspecs/win32-g++-cross-x64' -o .obj/release-static/qstring.o /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qstring.cpp /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qsimd.cpp: In function 'uint detectProcessorFeatures()': /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qsimd.cpp:296:23: error: '__cpuid' was not declared in this scope __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 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 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
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 is successful with mingw-w64 r5915
(20130628), but with the mingw-w64 r5949 (20130713) the build fails for
the x86_64-w64-mingw32 target with this error:
x86_64-w64-mingw32-g++ -c -include .obj/release-static/qt_pch.h -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 --param=ssp-buffer-size=4
-fno-keep-inline-dllexport -O2 -Wall -frtti -fexceptions -mthreads
-DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB
-DQT_NO_USING_NAMESPACE -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES
-DQLIBRARYINFO_EPOCROOT -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG
-DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT
-DQT_HAVE_SSE2 -DQT_HAVE_SSE3 -DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1
-DQT_HAVE_SSE4_2 -DQT_HAVE_AVX -I'../../include'
-I'../../include/QtCore' -I'.rcc/release-static' -I'tmp' -I'global'
-I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/tools/shared'
-I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/harfbuzz/src'
-I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/md5'
-I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/3rdparty/md4'
-I'../../include/ActiveQt' -I'.moc/release-static' -I'.'
-I'/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/mkspecs/win32-g++-cross-x64'
-o .obj/release-static/qstring.o
/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qstring.cpp
/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qsimd.cpp:
In function 'uint detectProcessorFeatures()':
/builddir/build/BUILD/qt-everywhere-opensource-src-4.8.5/src/corelib/tools/qsimd.cpp:296:23:
error: '__cpuid' was not declared in this scope
__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 be found at
http://koji.fedoraproject.org/koji/taskinfo?taskID=5605337
Have you got any idea what might be going wrong here?
According to a git bisect commit 5924 is the culprit (Intrin clean up).
In this commit an #include intrin.h was removed from winnt.h:
--
@@ -1490,23 +1446,14 @@ extern C {
# if defined(__cplusplus)
}
# endif
-#else /* !__CYGWIN__ */
-# include intrin.h
-#endif /* __CYGWIN__ */
#define FastFence __faststorefence86__) || defined(_IA64_))
--
Due to this change the file intrin.h (which contains the declaration for
__cpuid) isn't #include'd automatically any more when only #include
winnt.h is used.
As Qt4's qsimd.cpp doesn't #include intrin.h directly the build fails.
According to MSDN an #include intrin.h is needed to make __cpuid
available so I think this is an issue at the Qt4 side and not the
mingw-w64 side.
I've patched around it for now in the Qt4 package as I think mingw-w64
is doing 'the right thing' here and Qt4 should follow the documented
behavior.
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 and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
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 started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. Just a heads up that this regression is resolved now in mingw-w64 trunk. This is probably due to r5949 which was committed today (which changes the way the Interlocked symbols are implemented in mingw-w4). In Fedora we've dropped our local patch which was used to temporary workaround the issue. Regards, Erik van Pienbroek Fedora MinGW SIG -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for June 30 2013
This is a report for the 20130630 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. 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 in Fedora 20 once all build failures which are caused by it are resolved. The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet) During this mass rebuild the following toolchain was used: * mingw-w64 20130628 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.1 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130630 Total packages: 170 Number of failed packages: 8 Number of succeeded packages: 162 Number of added packages since previous mass rebuild: 6 Time needed to perform mass rebuild: 31 hours, 4 minutes, 39 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130512 Total packages: 164 Number of failed packages: 7 Number of succeeded packages: 157 === The following packages were added since the previous rebuild: mingw-glew mingw-gtkglext mingw-gtkspell3 mingw-gtkspellmm30 mingw-winpthreads mingw-winstorecompat === 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-rebuild/20130630/mingw-glew-1.9.0-4 mingw-gstreamer-0.10.36-3 Package owner: pfor Time to build: 2 minutes, 8 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-gstreamer-0.10.36-3 mingw-gstreamer1-1.0.6-1 Package owner: pfor Time to build: 2 minutes, 6 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-gstreamer1-1.0.6-1 mingw-libidn-1.25-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 3 minutes, 6 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libidn-1.25-2 mingw-libtasn1-3.3-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 1 minute, 44 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libtasn1-3.3-2 mingw-libvirt-1.0.5-2 Package owner: berrange Time to build: 3 minutes, 57 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libvirt-1.0.5-2 mingw-tcl-8.5.13-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 3 minutes, 34 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-tcl-8.5.13-2 mingw-wine-gecko-2.21-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: awjb Time to build: 1 hour, 18 minutes, 51 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-wine-gecko-2.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 epien...@fedoraproject.org - 0-0.6.svn2215.20130517 - Export various symbols from the hlsl translator static library in the libGLESv2.dll shared library as they are needed by mingw-qt5-qtwebkit. The symbols in question are marked as NONAME (hidden) * Fri May 17 2013 Erik van Pienbroek epien...@fedoraproject.org - 0-0.5.svn2215.20130517 - Update to 20130517 snapshot (r2215) mingw-atkmm-2.22.7-2.fc19 -- * Sun Jun 16 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.22.7-2 - Rebuild to resolve InterlockedCompareExchange regression in mingw32 libraries * Sun Jun 09 2013 Kalev Lember kalevlem...@gmail.com - 2.22.7-1 - Update to 2.22.7 - Drop the pkgconfig deps mingw-clucene-2.3.3.4-7.fc19 - * Fri May 31 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.3.3.4-7 - Don't use pthreads on win32 even when it is available (clucene uses the win32 threading API directly) mingw-crt-2.0.999-0.28.trunk.r5915.20130628.fc19 - * Fri Jun 28 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.28.trunk.r5915.20130628
Re: [Mingw-w64-public] Mass rebuild report for June 30 2013
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-rebuild/20130630/mingw-glew-1.9.0-4 strip:/builddir/build/BUILDROOT/mingw-glew-1.9.0-4.fedora_rebuild_20130628.i386/usr/x86_64-w64-mingw32/sys-root/mingw/bin/glewinfo.exe: File format not recognized install: strip process terminated abnormally strip:/builddir/build/BUILDROOT/mingw-glew-1.9.0-4.fedora_rebuild_20130628.i386/usr/x86_64-w64-mingw32/sys-root/mingw/bin/visualinfo.exe: File format not recognized install: strip process terminated abnormally make: *** [install.bin] Error 1 Wrong strip called from install -s? Thanks for taking an initial look at the failures! I've did some more testing on this one and it appears to only happen when the package is built on a i686 host (on a x86_64 host it works fine). The underlying issue is that this package shouldn't use the native Linux 'strip' tool, but the tool 'mingw-strip'. (minor note: 'mingw-strip' is a Fedora specific tool, normally people should use either 'i686-w64-mingw32-strip' or 'x86_64-w64-mingw32-strip) mingw-gstreamer-0.10.36-3 Package owner: pfor Time to build: 2 minutes, 8 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-gstreamer-0.10.36-3 .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_resolution': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:550: undefined reference to `clock_getres' .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_internal_time': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:524: undefined reference to `clock_gettime' .libs/libgstreamer_0.10_la-gstutils.o: In function `gst_util_get_timestamp': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstutils.c:3940: undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status kai, are these exported from winpthreads? mingw-gstreamer1-1.0.6-1 Package owner: pfor Time to build: 2 minutes, 6 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-gstreamer1-1.0.6-1 Likewise. These are is indeed winpthreads related. This issue was already reported to the mingw-w64 mailing list some time ago: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/7447 mingw-libidn-1.25-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 3 minutes, 6 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libidn-1.25-2 ../../gl/msvc-inval.c:32:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gl_msvc_invalid_parameter_handler' gl_msvc_invalid_parameter_handler (const wchar_t *expression, ^ ../../gl/msvc-inval.c: In function 'gl_msvc_inval_ensure_handler': ../../gl/msvc-inval.c:124:39: error: 'gl_msvc_invalid_parameter_handler' undeclared (first use in this function) _set_invalid_parameter_handler (gl_msvc_invalid_parameter_handler); ^ ../../gl/msvc-inval.c:124:39: note: each undeclared identifier is reported only once for each function it appears in IIRC there was some change to msvcrt.def mingw-libtasn1-3.3-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 1 minute, 44 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libtasn1-3.3-2 Likewise. mingw-libvirt-1.0.5-2 Package owner: berrange Time to build: 3 minutes, 57 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130630/mingw-libvirt-1.0.5-2 Likewise. These ones are caused by an issue in gnulib (which all these packages use). It was already reported upstream by LRN recently. Upstream has applied a fix for it at http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=86725346a1b116f3c2da26c124288f5f4495bf69 Packagers are encouraged to nag upstream to update their bundled copy of gnulib or manually apply the mentioned patch for now. In mingw-libvirt there's also an additional failure caused by winpthreads (related to pthread_sigmask). I reported this issue to the upstream libvirt devs, but they pointed me back to the mingw-w64 devs. Therefore I already sent this mail to the mingw-w64 mailing list some time ago but I'm still waiting for a reply: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/7507 mingw-tcl-8.5.13-2 ** Package failed to build while it succeeded during the previous mass rebuild
Re: [Mingw-w64-public] Mass rebuild report for June 30 2013
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/git/gitweb.cgi?p=cygwin-ports/mingw64-i686-glew;a=blob_plain;f=1.7.0-no-strip.patch;h=f8544e6;hb=HEAD Yaakov Cygwin Ports I've forwarded this information to the package maintainer of the mingw-glew package. Thank you very much for the patch! -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
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-w64 toolchain where it will be used until a proper solution has come up. Unfortunately a similar issue has also started to show up on the x86_64 target. As of r5898 shared libraries (which are generated without an explicit .def file) start to export the symbol __mingw_get_msvcrt_handle as can be seen with this minimal testcase: $ touch foo.c $ cat foo.c $ x86_64-w64-mingw32-gcc -shared foo.c -o foo.dll $ x86_64-w64-mingw32-objdump -p foo.dll | grep -A2 '\[Ordinal/Name Pointer\] Table' [Ordinal/Name Pointer] Table [ 0] __mingw_get_msvcrt_handle In Fedora we've also reversed this specific commit (r5898) for now until a proper solution comes up. Regards, Erik van Pienbroek -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
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 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-w64 toolchain where it will be used until a proper solution has come up. Regards, Erik van Pienbroek --- mingw-w64-crt/Makefile.am.revert_r5713 2013-06-13 17:27:36.0 +0200 +++ mingw-w64-crt/Makefile.am 2013-06-14 17:46:50.774319773 +0200 @@ -154,7 +154,7 @@ secapi/wmemcpy_s.c -src_libmingwex=\ +src_libmingwex=intrincs/ilockcxch.c\ crt/dllentry.ccrt/dllmain.c \ \ complex/cabs.c complex/cabsf.ccomplex/cabsl.c complex/cacos.ccomplex/cacosf.c complex/cacosl.c \ @@ -258,7 +258,7 @@ intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c intrincs/bitscanfwd.cintrincs/bitscanrev.c \ intrincs/bittest.cintrincs/bittestc.c intrincs/bittestci.c intrincs/bittestr.c intrincs/bittestri.c \ intrincs/bittests.c intrincs/bittestsi.c intrincs/cpuid.c intrincs/currentfiber.c intrincs/currentteb.c \ - intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.cintrincs/ilockand64.cintrincs/ilockcxch.c \ + intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.cintrincs/ilockand64.c\ intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.cintrincs/ilockdec.c intrincs/ilockdec16.c \ intrincs/ilockdec64.c intrincs/ilockexch.c intrincs/ilockexch64.c intrincs/ilockexchadd.c intrincs/ilockexchadd64.c \ intrincs/ilockexchptr.c intrincs/ilockinc.c intrincs/ilockinc16.c intrincs/ilockinc64.cintrincs/ilockor.c\ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
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 [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange snip So even when an empty library is built it will export the two InterlockedCompareExchange symbols.. Any news on this issue? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] pthread_sigmask in winpthreads
Hi, In our quest to enable winpthreads in Fedora we've stumbled across a new issue. Libvirt fails to build with this linker error: CCLD libvirt.la ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientIOEventLoop': /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1521: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1528: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1528: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientSetTLSSession': /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:795: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:802: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:819: more undefined references to `pthread_sigmask' follow Upon a closer look this particular function is #define'd to a no-op in pthread.h: $ grep pthread_sigmask /usr/i686-w64-mingw32/sys-root/mingw/include/pthread.h #define pthread_sigmask(H, S1, S2) 0 So I tried to report this issue to the upstream libvirt devs: https://bugzilla.redhat.com/show_bug.cgi?id=969231 They replied back to me with the message that according to the official documentation the declaration for pthread_sigmask should be in signal.h: http://pubs.opengroup.org/onlinepubs/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 service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Exporting clock_* symbols in the mingw crt instead of winpthreads?
Hi, While trying to compile all Fedora packages against winpthreads [1] we found out that gstreamer fails to build with this linker error: CCLD libgstreamer-0.10.la .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_resolution': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:550: undefined reference to `clock_getres' .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_internal_time': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:524: undefined reference to `clock_gettime' .libs/libgstreamer_0.10_la-gstutils.o: In function `gst_util_get_timestamp': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstutils.c:3940: undefined reference to `clock_gettime' I took a closer look at this and here's what happens: The gstreamer configure script tests whether the #define's _POSIX_TIMERS and CLOCK_REALTIME are set. This test succeeds as these are both set in winpthreads' pthread_time.h. Therefore the build system makes the assumption that symbols like clock_getres and clock_gettime are available. The documentation about these clock_* symbols tells us that these symbols are POSIX specific and are part of libc (for glibc = 2.17 the linker flag -lrt must be used) In mingw-w64 these symbols are exported in winpthreads, thus -lpthread need to be part of the linker flags. Gstreamer isn't aware that -lpthread needs to be part of the linker flags for these clock_* symbols and therefore the build fails. I could find any documentation that these clock_* symbols may be part of the pthread library so I think that in mingw-w64 these symbols shouldn't be exported in winpthreads. 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://sourceforge.net/mailarchive/message.php?msg_id=30821407 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
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 started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. 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 [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange snip So even when an empty library is built it will export the two InterlockedCompareExchange symbols.. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Website] Work on a Download page
Adrien Nader schreef op ma 20-05-2013 om 11:17 [+0200]: As you can see on the page, besides the layout which isn't perfect, the toolchain descriptions are completely wrong. If you maintain such a toolchain and wish to be listed on the download page, please provide me with a toolchain description. Hi Adrien, I don't know if you also want to add Linux distributions which provide mingw-w64 toolchains to the list (like openSuSE and Debian), but here's information about the mingw-w64 toolchains in the various Fedora releases: Fedora 17 (will be end-of-life in august 2013): * mingw-w64 trunk 20121016 snapshot * gcc 4.7.2 * binutils 2.22.52 * pthreads-w32 as default pthread implementation Fedora 18: * mingw-w64 trunk 20121110 snapshot * gcc 4.7.2 * binutils 2.23.1 * pthreads-w32 as default pthread implementation Fedora 19 (currently in Beta freeze): * mingw-w64 trunk 20130509 snapshot * gcc 4.8.0 * binutils 2.23.52.0.1 * pthreads-w32 as default pthread implementation Fedora 20 (also named 'rawhide', scheduled for fall 2013): * mingw-w64 trunk 20130509 snapshot * gcc 4.8.0 * binutils 2.23.52.0.1 * winpthreads as default pthread implementation (planned) * support for c++11 std::thread (planned) We've got the following additional software in all releases of Fedora which were already mentioned on your list: * atk * cairo * curl * freetype * gdb * gtk+ (both gtk2 and gtk3) * libarchive * libogg * libtheora * openssl * pango * Qt (both qt4 and qt5) * xz The complete list is much larger than this and can be found at https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-* All mingw packages can be installed with the default package manager in Fedora called yum (or any of its graphical frontends). No additional configuration 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 Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for May 12 2013
This is a report for the 20130512 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. This is the first mass rebuild which uses winpthreads instead of the old pthreads-w32 implementation. The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet) During this mass rebuild the following toolchain was used: * mingw-w64 20130509 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.0 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130512 Total packages: 164 Number of failed packages: 6 Number of succeeded packages: 158 Number of added packages since previous mass rebuild: 1 Time needed to perform mass rebuild: 35 hours, 11 minutes, 57 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130427 Total packages: 163 Number of failed packages: 4 Number of succeeded packages: 159 === The following packages were added since the previous rebuild: mingw-winpthreads === The following packages FAILED to rebuild: mingw-clucene-2.3.3.4-6 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 4 minutes, 59 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-clucene-2.3.3.4-6 mingw-gstreamer-0.10.36-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 4 minutes, 28 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gstreamer-0.10.36-3 mingw-gstreamer1-1.0.6-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 4 minutes, 17 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gstreamer1-1.0.6-1 mingw-gtk3-3.9.0-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 5 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gtk3-3.9.0-1 mingw-libvirt-0.10.2-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: berrange Time to build: 8 minutes, 47 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-libvirt-0.10.2-3 mingw-sqlite-3.7.16.2-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 3 minutes, 21 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-sqlite-3.7.16.2-1 === The following packages were updated since the previous rebuild: mingw-crt-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...@fedoraproject.org - 2.0.999-0.22.trunk.20130509 - Update to 20130509 snapshot * Sun Apr 28 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.21.trunk.20130428 - Update to 20130428 snapshot - Fixes build regression in wxWidgets and tcl regarding the timezone function mingw-fontconfig-2.10.92-1.fc19 * Sat May 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.10.92-1 - Update to 2.10.92 mingw-gdb-7.6-1.fc19 - * Sat May 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 7.6-1 - Update to 7.6 mingw-gettext-0.18.2.1-1.fc19 -- * Sat May 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 0.18.2.1-1 - Update to 0.18.2.1 mingw-glib-networking-2.37.1-1.fc19 * Thu May 09 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.37.1-1 - Update to 2.37.1 mingw-glib2-2.37.0-1.fc19 -- * Sun May 05 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.37.0-1 - Update to 2.37.0 mingw-glibmm24-2.36.2-1.fc19 - * Mon May 06 2013 Thomas Sailer t.sai...@alumni.ethz.ch - 2.36.2-1 - update to 2.36.2 mingw-gmp-5.1.1-1.fc19 --- * Thu May 09 2013 Michael Cronenworth m...@cchtml.com - 5.1.1-1 - New upstream release. mingw-gnutls-3.1.10-1.fc19 --- * Thu May 09
Re: [Mingw-w64-public] Mass rebuild report for May 12 2013
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 repositories. mingw-clucene-2.3.3.4-6 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 4 minutes, 59 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-clucene-2.3.3.4-6 In file included from /builddir/build/BUILD/clucene-core-2.3.3.4/src/core/CLucene/debug/lucenebase.h:10:0, from /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/SharedHeader.h:201, from /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/_SharedHeader.h:13, from /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/SharedHeader.cpp:8: /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:43:41: error: 'pthread_t' does not name a type #define _LUCENE_THREADID_TYPE pthread_t ^ mingw-gstreamer-0.10.36-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 4 minutes, 28 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gstreamer-0.10.36-3 mingw-gstreamer1-1.0.6-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: pfor Time to build: 4 minutes, 17 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gstreamer1-1.0.6-1 Both versions of gstreamer have the same issue: CCLD libgstreamer-0.10.la .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_resolution': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:550: undefined reference to `clock_getres' .libs/libgstreamer_0.10_la-gstsystemclock.o: In function `gst_system_clock_get_internal_time': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstsystemclock.c:524: undefined reference to `clock_gettime' .libs/libgstreamer_0.10_la-gstutils.o: In function `gst_util_get_timestamp': /builddir/build/BUILD/gstreamer-0.10.36/build_win32/gst/../../gst/gstutils.c:3940: undefined reference to `clock_gettime' mingw-gtk3-3.9.0-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: kalev Time to build: 5 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-gtk3-3.9.0-1 Not winpthreads related. During the build an attempt is done to execute a cross-compiled executable. Upstream has just provided a patch to fix this issue, but it requires an additional change in mingw-filesystem regarding the use of pkg-config environment variables: https://bugzilla.gnome.org/show_bug.cgi?id=699690 mingw-libvirt-0.10.2-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: berrange Time to build: 8 minutes, 47 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-libvirt-0.10.2-3 CCLD libvirt.la ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientIOEventLoop': /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1521: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1528: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:1528: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientSetTLSSession': /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:795: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:802: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-0.10.2/build_win32/src/../../src/rpc/virnetclient.c:819: more undefined references to `pthread_sigmask' follow mingw-sqlite-3.7.16.2-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 3 minutes, 21 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130512/mingw-sqlite-3.7.16.2-1 libtool: compile: x86_64-w64-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4
[Mingw-w64-public] [PATCH] Add vsprintf_s wrapper
Hi,
Recently one of our users reported an issue where an attempt was done to
run a Qt5 based application on Windows XP [1]. Upon startup the user got
a fatal error that the symbol vsprintf_s couldn't be found in
msvcrt.dll. It turned out that this symbol is only available in the
msvcrt.dll in later versions of Windows.
As the mingw-w64-crt already contains various wrappers for other secure
API functions I decided to implement a wrapper for vsprintf_s as well.
We've been using this patch for some time now in Fedora without issues
and we would like to propose it for inclusion 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 Pienbroek
Fedora MinGW SIG
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=917323
--- mingw-w64-crt/Makefile.am.orig 2013-03-04 19:48:33.103373245 +0100
+++ mingw-w64-crt/Makefile.am 2013-03-04 19:49:42.175932725 +0100
@@ -244,6 +244,7 @@
secapi/_vcprintf_s.c secapi/_vcprintf_s_l.c \
secapi/_cwprintf_s.c secapi/_cwprintf_s_l.c \
secapi/_vcwprintf_s.c secapi/_vcwprintf_s_l.c \
+ secapi/vsprintf_s.c \
secapi/_access_s.c secapi/_waccess_s.c \
secapi/_chsize_s.c secapi/_mktemp_s.c secapi/_wmktemp_s.c \
secapi/_umask_s.c \
--- /dev/null 2013-03-03 23:07:12.487394095 +0100
+++ mingw-w64-crt/secapi/vsprintf_s.c 2013-03-04 19:48:26.188317233 +0100
@@ -0,0 +1,40 @@
+#include windows.h
+#include malloc.h
+#include errno.h
+
+HMODULE __mingw_get_msvcrt_handle(void);
+int __cdecl vsprintf (char *, const char *, va_list);
+int __cdecl vsprintf_s (char *, size_t, const char *, va_list);
+static int __cdecl _int_vsprintf_s (char *, size_t, const char *, va_list);
+static int __cdecl _stub (char *, size_t, const char *, va_list);
+
+int __cdecl (*__MINGW_IMP_SYMBOL(vsprintf_s))(char *, size_t, const char *, va_list) =
+ _stub;
+
+static int __cdecl
+_stub (char *_DstBuf, size_t _Size, const char *_Format, va_list _ArgList)
+{
+ int __cdecl (*f)(char *, size_t, const char *, va_list) = __MINGW_IMP_SYMBOL(vsprintf_s);
+
+ if (f == _stub)
+{
+ f = (int __cdecl (*)(char *, size_t, const char *, va_list))
+ GetProcAddress (__mingw_get_msvcrt_handle (), vprintf_s);
+ if (!f)
+ f = _int_vsprintf_s;
+ __MINGW_IMP_SYMBOL(vsprintf_s) = f;
+}
+ return (*f)(_DstBuf, _Size, _Format, _ArgList);
+}
+
+int __cdecl
+vsprintf_s (char *_DstBuf, size_t _Size, const char *_Format, va_list _ArgList)
+{
+ return _stub (_DstBuf, _Size, _Format, _ArgList);
+}
+
+static int __cdecl
+_int_vsprintf_s (char *_DstBuf, size_t _Size, const char *_Format, va_list _ArgList)
+{
+ return vsprintf (_DstBuf, _Format, _ArgList);
+}
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Add declaration for HidD_GetHidGuid
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://msdn.microsoft.com/en-us/library/ff538924%28v=vs.85%29.aspx --- mingw-w64-headers/include/hidsdi.h.orig 2013-05-09 13:02:00.501973553 +0200 +++ mingw-w64-headers/include/hidsdi.h 2013-05-09 13:02:42.189673325 +0200 @@ -41,6 +41,10 @@ HidD_SetFeature(HANDLE HidDeviceObject, PVOID ReportBuffer, ULONG ReportBufferLength); + /* http://msdn.microsoft.com/en-us/library/ff538924(v=vs.85).aspx */ +HIDAPI VOID NTAPI +HidD_GetHidGuid(LPGUID HidGuid); + #ifdef __cplusplus } #endif -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for April 27 2013
This is a report for the 20130427 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 20130425 trunk snapshot * binutils 2.23.52.0.1 * gcc 4.8.0 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130427 Total packages: 163 Number of failed packages: 4 Number of succeeded packages: 159 Number of added packages since previous mass rebuild: 0 Time needed to perform mass rebuild: 31 hours, 11 minutes, 17 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20130406 Total packages: 163 Number of failed packages: 0 Number of succeeded packages: 163 === 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 to 20130425 snapshot mingw-eigen3-3.1.3-1.fc19 -- * Fri Apr 19 2013 Sandro Mani manisan...@gmail.com - 3.1.3-1 - Update to release 3.1.3 mingw-gcc-4.8.0-3.fc19 --- * Sun Apr 14 2013 Nicola Fontana n...@entidi.it - 4.8.0-3 - Dropped dependency on PPL (#951914) * Sun Apr 14 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.8.0-2 - Fix optimization bug which can lead to uncaught throw (SEH related) (GCC bug #56742) mingw-glib2-2.36.1-1.fc19 -- * Tue Apr 16 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.36.1-1 - Update to 2.36.1 - Dropped upstreamed patches * Mon Apr 15 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.36.0-3 - Revert unintended ABI break on win64 (RHBZ #951588, GNOME BZ #697879) mingw-headers-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 to 20130425 snapshot mingw-libxml2-2.9.1-1.fc19 --- * Sat Apr 20 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.9.1-1 - Update to 2.9.1 * Fri Apr 12 2013 Nicola Fontana n...@entidi.it - 2.9.0-3 - Throw off LDFLAGS and CFLAGS settings (#951472) - Simplified static libraries installation mingw-pkg-config-0.28-1.fc19 - * Sat Apr 13 2013 Kalev Lember kalevlem...@gmail.com - 0.28-1 - Update to 0.28 * Sat Apr 13 2013 Kalev Lember kalevlem...@gmail.com - 0.27.1-1 - Update to 0.27.1 mingw-pthreads-2.8.0-23.20110511cvs.fc19 - * Thu Apr 11 2013 Nicola Fontana n...@entidi.it - 2.8.0-23.20110511cvs - Removed sed substitutions mingw-qt-4.8.4-3.fc19 -- * Sun Apr 14 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.8.4-3 - QSslSocket may report incorrect errors when certificate verification fails mingw-spice-gtk-0.19-1.fc19 * Thu Apr 11 2013 Marc-André Lureau marcandre.lur...@redhat.com - 0.19-1 - Update to spice-gtk 0.19 === 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 Time to build: 4 minutes, 58 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130427/mingw-gettext-0.18.2-2 mingw-openssl-1.0.1e-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 9 minutes, 37 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130427/mingw-openssl-1.0.1e-1 mingw-tcl-8.5.13-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 2 minutes, 21 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130427/mingw-tcl-8.5.13-2 mingw-wxWidgets-2.8.12-13 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 12 minutes, 48 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130427/mingw-wxWidgets-2.8.12-13 === The following packages were rebuilt successfully: mingw-angleproject-0-0.4.svn1561.20121214 Time to build: 2 minutes, 46 seconds mingw-antlr-2.7.7-11 Time to build: 2 minutes, 17 seconds mingw-atk-2.8.0-1 Time to build: 2 minutes, 3 seconds mingw-atkmm-2.22.6-6 Time to build: 2 minutes, 35 seconds mingw
Re: [Mingw-w64-public] Mass rebuild report for April 27 2013
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 the previous mass rebuild ** Package owner: rjones Time to build: 4 minutes, 58 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130427/mingw-gettext-0.18.2-2 /usr/i686-w64-mingw32/sys-root/mingw/include/stdio.h:319:5: error: previous declaration of 'int asprintf(char**, const char*, ...)' with 'C ++' linkage int asprintf(char **__ret, const char *__format, ...) ^ In file included from ../../../gettext-runtime/libasprintf/lib-asprintf.h:30:0, from ../../../gettext-runtime/libasprintf/autosprintf.cc:31: ../../../gettext-runtime/libasprintf/vasprintf.h:45:54: error: conflicts with new declaration with 'C' linkage __attribute__ ((__format__ (__printf__, 2, 3))); This looks like a change in mingw-w64 regarding the declaration of asprintf. Could one of the mingw-w64 devs take a look at this and indicate whether this should be fixed in mingw-w64 itself or in gettext? Hi, Can you retry? This was fixed very recently, depending on your timezone, it may be on the 25th or 26th. The mass-rebuild was done against mingw-w64 trunk r5820 (I just verified this to be absolutely certain). This is still the latest mingw-w64 commit at the time of writing this mail so I guess the problem is still there. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GStreamer Crash
Kyle Schwarz schreef op di 16-04-2013 om 21:47 [-0400]: I had very few issues compiling the dependencies for GStreamer. I did have to edit the code of glib or GStreamer to change a multiple definition of DllMain. I am trying to compile the build statically. I can't help you with the gstreamer crash in wine (it contains too little information to say where the crash is exactly happening), but for the multiple definition of DllMain I recently proposed a patch to glib upstream which fixes that one. It might help for your case as well: https://bugzilla.gnome.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 apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GStreamer Crash
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://pkgs.fedoraproject.org/cgit/mingw-glib2.git/plain/glib-prefer-constructors-over-DllMain.patch 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 for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for April 06 2013
This is a report for the 20130406 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which
have been applied since the previous mass rebuild.
During this mass rebuild the following toolchain was used:
* mingw-w64 20130403 trunk snapshot
* binutils 2.23.52.0.1
* gcc 4.8.0
Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20130406
Total packages: 163
Number of failed packages: 0
Number of succeeded packages: 163
Number of added packages since previous mass rebuild: 6
Time needed to perform mass rebuild: 34 hours, 9 minutes, 47 seconds
Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20130122
Total packages: 157
Number of failed packages: 2
Number of succeeded packages: 155
===
The following packages were added since the previous rebuild:
mingw-dbus-glib
mingw-eigen3
mingw-GConf2
mingw-gstreamer1
mingw-gstreamer1-plugins-base
mingw-libwebp
mingw-polyclipping
===
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 that the gyp
build system doesn't properly support cross-compilation
Fixes FTBFS against latest gyp
* Fri Jan 25 2013 Erik van Pienbroek epien...@fedoraproject.org -
0-0.3.svn1561.20121214
- Added license
- Resolved various rpmlint warnings
- Prefix the release tag with '0.'
* Mon Dec 24 2012 Erik van Pienbroek epien...@fedoraproject.org -
0-0.2.svn1561.20121214
- Added -static subpackages
mingw-atk-2.8.0-1.fc19
---
* Tue Mar 26 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.8.0-1
- Update to 2.8.0
* Sun Mar 24 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.7.91-1
- Update to 2.7.91
mingw-binutils-2.23.52.0.1-1.fc19
--
* Wed Apr 03 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.23.52.0.1-1
- Update to 2.23.52.0.1
- Fixes FTBFS against latest texinfo
- Resolve build failure on PPC
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.23.51.0.5-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
* Tue Jan 22 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.23.51.0.5-3
- Backported patch to fix 'unexpected version string length' error in windres
(RHBZ #902960)
mingw-boost-1.53.0-1.fc19
--
* Sun Mar 03 2013 Thomas Sailer t.sai...@alumni.ethz.ch - 1.53.0-1
- update to 1.53.0
mingw-cairo-1.12.14-2.fc19
---
* Tue Apr 02 2013 Marc-Andr� Lureau marcandre.lur...@redhat.com - 1.12.14-2
- Fix corrupted drawing, cherry-picked from upstream (fdo#61876)
- Add a few windows related fixes
* Fri Mar 29 2013 Kalev Lember kalevlem...@gmail.com - 1.12.14-1
- Update to 1.12.14
mingw-crossreport-8-5.fc19
---
* Thu Apr 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 8-5
- Added BR: perl-podlators for Fedora 19 and above
mingw-crt-2.0.999-0.19.trunk.20130403.fc19
---
* Wed Apr 03 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.19.trunk.20130403
- Update to 20130403 snapshot
- Added Windows XP compatibility wrapper for the vsprintf_s function (RHBZ
#917323)
* Sat Feb 16 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.18.trunk.20130216
- Update to 20130216 snapshot
- Includes improved import libraries (for setupapi, cfgmgr32 and others)
* Sun Jan 27 2013 Erik van Pienbroek epien...@fedoraproject.org -
2.0.999-0.17.trunk.20130127
- Update to 20130127 snapshot
mingw-curl-7.29.0-1.fc19
-
* Sun Mar 24 2013 Erik van Pienbroek epien...@fedoraproject.org - 7.29.0-1
- Update to 7.29.0
mingw-filesystem-97-3.fc19
---
* Thu Feb 28 2013 Ralf Cors�pius corse...@fedoraproject.org - 97-3
- Remove %config from %{_sysconfdir}/rpm/macros.*
(https://fedorahosted.org/fpc/ticket/259).
- Minor spec fixes.
mingw-gcc-4.8.0-1.fc19
---
* Sat Mar 23 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.8.0-1
- Update to gcc 4.8.0 final
* Mon Mar 11 2013 Erik van Pienbroek epien...@fedoraproject.org -
4.8.0-0.6.svn.20130310.r196584
- Update to gcc 4.8 20130310 snapshot (rev 196584)
* Fri Feb 08 2013 Erik van Pienbroek epien...@fedoraproject.org -
4.8.0-0.5.svn.20130203.r195703
- Update to gcc 4.8 20130203 snapshot (rev 195703)
* Sun Jan 27 2013 Erik van Pienbroek epien...@fedoraproject.org -
4.8.0-0.4.svn.20130120.r195326
- Update to gcc 4.8 20130120 snapshot (rev 195326)
mingw-gdk-pixbuf-2.28.0-1.fc19
Re: [Mingw-w64-public] SetupUninstallOEMInf linking issue
Marc-André Lureau schreef op vr 25-01-2013 om 22:29 [+0100]: Hi, Using mingw32-gcc-4.7.2-2.fc18.x86_64 mingw32-crt-2.0.999-0.15.trunk.20121110.fc18.noarch I am wondering against which library I should be linking, -lsetupapi doesn't seem to have the symbol: undefined reference to `_imp__SetupUninstallOEMInfW@12' Thanks for your help! Hi Marc-André, I just did a quick grep through the mingw-w64 source code and it looks like the symbol in question is only available on the win64 target: $ grep -Hr SetupUninstallOEMInf * mingw-w64-crt/lib64/setupapi.def:SetupUninstallOEMInfA mingw-w64-crt/lib64/setupapi.def:SetupUninstallOEMInfW mingw-w64-headers/include/setupapi.h:#define SetupUninstallOEMInf __MINGW_NAME_AW(SetupUninstallOEMInf) mingw-w64-headers/include/setupapi.h: WINSETUPAPI WINBOOL WINAPI SetupUninstallOEMInfA(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 whether this is intended? Regards, Erik van Pienbroek -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Results of mass rebuild against gcc 4.8
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
* gcc 4.8.0 20130113 snapshot, r195137
Total number of packages: 157
Number of failed packages: 32
As follow-up to this mail, we managed to reduce the amount of build
failures to just two. The only packages remaining now are mingw-qpid-cpp
and wine-mono.
A bug report was filed against gcc, but upstream hasn't replied to it
yet. For now I'm carrying a patch in the mingw-gcc package which will be
replaced once upstream comes with a more appropriate solution. This
patch is needed to get mingw-qt5-qtbase built. The bug report (including
a proposed patch) can be found at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 - declarations in
xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
The wine-mono package failed to build due to a removed feature in
automake (and not due to gcc 4.8):
--
Running automake --gnu ...
snip
runtime/Makefile.am:2: error: support for Cygnus-style trees has been
removed
--
The mingw-qpid-cpp package failed to build with this error:
--
[ 29%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/framing/AMQP_ClientProxy.obj
cd /builddir/build/BUILD/qpid-0.14/build_win32/src
/usr/bin/i686-w64-mingw32-g++ -DHAVE_CONFIG_H -Dqpidcommon_EXPORTS
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -Werror -pedantic -Wall -Wextra -Wno-shadow
-Wpointer-arith -Wno-error=delete-non-virtual-dtor -Wno-error=narrowing
-fpermissive -Wcast-align -Wno-long-long -Wvolatile-register-var
-Winvalid-pch -Wno-system-headers -Woverloaded-virtual -O2 -g -DNDEBUG
@CMakeFiles/qpidcommon.dir/includes_CXX.rsp -o
CMakeFiles/qpidcommon.dir/qpid/framing/AMQP_ClientProxy.obj
-c
/builddir/build/BUILD/qpid-0.14/build_win32/src/qpid/framing/AMQP_ClientProxy.cpp
In file included
from /builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/FrameHandler.h:23:0,
from /builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/Proxy.h:22,
from
/builddir/build/BUILD/qpid-0.14/build_win32/src/qpid/framing/AMQP_ClientProxy.h:30,
from
/builddir/build/BUILD/qpid-0.14/build_win32/src/qpid/framing/AMQP_ClientProxy.cpp:29:
/builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/Handler.h:52:47:
error: invalid use of incomplete type 'struct
qpid::framing::HandlerT' [-Werror]
template class F class Functor : public HandlerT {
^
/builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/Handler.h:32:8:
error: declaration of 'struct qpid::framing::HandlerT' [-Werror]
struct Handler {
^
/builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/Handler.h:64:30:
error: invalid use of incomplete type 'struct
qpid::framing::HandlerT' [-Werror]
class MemFunRef : public HandlerT {
^
/builddir/build/BUILD/qpid-0.14/cpp/src/qpid/framing/Handler.h:32:8:
error: declaration of 'struct qpid::framing::HandlerT' [-Werror]
struct Handler {
^
cc1plus: all warnings being treated as errors
make[2]: ***
[src/CMakeFiles/qpidcommon.dir/qpid/framing/AMQP_ClientProxy.obj] Error
1
--
The complete build logs can be found at:
http://build1.openftd.org/fedora-mingw-rebuild/20130122/wine-mono-0.0.8-1/
http://build1.openftd.org/fedora-mingw-rebuild/20130122/mingw-qpid-cpp-0.14-5/
The package maintainers of these two packages are BCC'ed to this mail so
they can resolve the build issues and try to get the fixes upstreamed.
To summarize: we're ready to introduce gcc 4.8 in Fedora 19!
Regards,
Erik van Pienbroek
Fedora MinGW SIG
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Results of mass rebuild against gcc 4.8
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 * gcc 4.8.0 20130113 snapshot, r195137 Total number of packages: 157 Number of failed packages: 32 The following packages failed to rebuild: mingw-antlr-2.7.7-10 mingw-celt051-0.5.1.3-10 mingw-glib2-2.35.4-1 mingw-libsigsegv-2.6-6 mingw-libsqlite3x-20071018-17 mingw-plotmm-0.1.2-14 mingw-qpid-cpp-0.14-5 mingw-qt5-qt3d-5.0.0-0.3.git2012.e4d3ccac mingw-qt5-qtactiveqt-5.0.0-1 mingw-qt5-qtbase-5.0.0-4 mingw-qt5-qtconnectivity-5.0.0-0.3.git20121112.63139e83 mingw-qt5-qtdeclarative-5.0.0-1 mingw-qt5-qtdoc-5.0.0-0.2.beta1.git20121112.0530cf09 mingw-qt5-qtfeedback-5.0.0-0.3.git20121112.d22ba2dd mingw-qt5-qtgraphicaleffects-5.0.0-1 mingw-qt5-qtimageformats-5.0.0-1 mingw-qt5-qtjsbackend-5.0.0-1 mingw-qt5-qtlocation-5.0.0-0.3.git20130111.ac83b242 mingw-qt5-qtmultimedia-5.0.0-1 mingw-qt5-qtpim-5.0.0-0.3.git20121112.2c24dab3 mingw-qt5-qtquick1-5.0.0-1 mingw-qt5-qtscript-5.0.0-1 mingw-qt5-qtsensors-5.0.0-0.3.git20121112.ac76c8d5 mingw-qt5-qtsvg-5.0.0-1 mingw-qt5-qtsystems-5.0.0-0.3.git20121112.511d739c mingw-qt5-qttools-5.0.0-1 mingw-qt5-qttranslations-5.0.0-0.2.beta1.git20121112.ad9181a5 mingw-qt5-qtwebkit-5.0.0-1 mingw-qt5-qtxmlpatterns-5.0.0-1 mingw-wine-gecko-1.8-1 mingw-zfstream-20041202-15 wine-mono-0.0.8-1 There are a number of packages in this list which failed to rebuild because automake 1.13.1 was introduced in Fedora Rawhide recently (which in my opinion should have never been released as it breaks backwards compatibility with a lot of projects). These packages failed to rebuild because of the latest automake: mingw-antlr-2.7.7-10 mingw-celt051-0.5.1.3-10 mingw-libsigsegv-2.6-6 mingw-libsqlite3x-20071018-17 mingw-plotmm-0.1.2-14 mingw-zfstream-20041202-15 wine-mono-0.0.8-1 These packages failed to build because of different behavior in gcc 4.8: mingw-glib2-2.35.4-1 (win64 only) mingw-qpid-cpp-0.14-5 (native Fedora qpid-cpp package also fails to build against gcc 4.8) mingw-qt5-qtbase-5.0.0-4 (possible conflict between gcc 4.8 x86intrin.h and mingw-w64 intrin.h headers) mingw-wine-gecko-1.8-1 The remaining qt5 packages failed to build because mingw-qt5-qtbase couldn't be built. The build logs for all these build failures can be found at http://build1.openftd.org/fedora-mingw-rebuild/20130118/ Before people start introducing workarounds for the automake 1.13.1 failures I would like to point out that a patch was applied in Fedora Rawhide yesterday (automake-1.13.1-3.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, Erik van Pienbroek Fedora MinGW SIG -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] abort() crashing for -Wl,-subsystem,windows
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-compiled Fedora qt5 packages I also noticed this behavior (gcc 4.7, mingw-w64 trunk). It's pretty annoying as gdb doesn't catch this by default. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for January 12 2013
This is a report for the 20130112 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 20130105 trunk snapshot * binutils 2.23.51.0.5 * gcc 4.7.2 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20130112 Total packages: 157 Number of failed packages: 0 Number of succeeded packages: 157 Number of added packages since previous mass rebuild: 6 Time needed to perform mass rebuild: 32 hours, 4 minutes, 16 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20121128 Total packages: 151 Number of failed packages: 1 Number of succeeded packages: 150 === The following packages were added since the previous rebuild: mingw-angleproject mingw-clucene mingw-lcms mingw-lcms2 mingw-libarchive mingw-libgsf === The following packages were updated since the previous rebuild: mingw-boost-1.50.0-1.fc19 -- * Tue Dec 04 2012 Thomas Sailer t.sai...@alumni.ethz.ch - 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 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 MINGW32_MAKE_ARGS and MINGW64_MAKE_ARGS. These environment variables can be used to provide additional target-specific arguments when using the %mingw_make macro * Mon Dec 03 2012 Erik van Pienbroek epien...@fedoraproject.org - 96-3 - Added support for RHEL6 mingw-gcc-4.7.2-7.fc19 --- * Wed Jan 02 2013 Erik van Pienbroek epien...@fedoraproject.org - 4.7.2-7 - Backported imported fix regarding virtual thunks as recommended by upstream mingw-w64 developers (gcc bug #55171) * Tue Dec 04 2012 Erik van Pienbroek epien...@fedoraproject.org - 4.7.2-6 - Re-enable libgomp support * Mon Dec 03 2012 Erik van Pienbroek epien...@fedoraproject.org - 4.7.2-5 - Temporary build without libgomp support because of the broken circular dependency between mingw-gcc and mingw-pthreads which was caused by the latest PPL update * Mon Dec 03 2012 Erik van Pienbroek epien...@fedoraproject.org - 4.7.2-4 - Made this package compatible with RHEL6 and RHEL7 - Build with --disable-ppl-version-check (fixes FTBFS against latest PPL) * Fri Nov 30 2012 Tom Callaway s...@fedoraproject.org - 4.7.2-3 - rebuild for new ppl/cloog mingw-gdb-7.5.1-1.fc19 --- * Sun Dec 02 2012 Kalev Lember kalevlem...@gmail.com - 7.5.1-1 - Update to 7.5.1 mingw-gettext-0.18.2-1.fc19 * Fri Jan 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 0.18.2-1 - Update to 0.18.2 - Removed all hacks as they're not needed any more * Thu Dec 06 2012 Erik van Pienbroek epien...@fedoraproject.org - 0.18.1.1-11 - Fix the build on RHEL6 (too old libtool) - Minor cleanup mingw-glib-networking-2.34.2-1.fc19 * Wed Nov 28 2012 Kalev Lember kalevlem...@gmail.com - 2.34.2-1 - Update to 2.34.2 mingw-glib2-2.35.3-3.fc19 -- * Thu Jan 03 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.35.3-3 - Resolve regression regarding linking against C++ code (GNOME BZ #690902) * Tue Jan 01 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.35.3-2 - Make sure g_log_default_handler uses the correct file descriptors for stdout and stderr * Tue Jan 01 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.35.3-1 - Update to 2.35.3 mingw-glibmm24-2.34.1-1.fc19 - * Wed Nov 28 2012 Kalev Lember kalevlem...@gmail.com - 2.34.1-1 - Update to 2.34.1 mingw-gtk2-2.24.14-1.fc19 -- * Thu Dec 06 2012 Kalev Lember kalevlem...@gmail.com - 2.24.14-1 - Update to 2.24.14 mingw-gtkmm30-3.6.0-1.fc19 --- * Thu Nov 29 2012 Kalev Lember kalevlem...@gmail.com - 3.6.0-1 - Update to 3.6.0 mingw-gtksourceview3-3.6.1-1.fc19 -- * Wed Nov 28 2012 Kalev Lember kalevlem...@gmail.com - 3.6.1-1 - Update to 3.6.1 mingw-harfbuzz-0.9.9-2.fc19 * Wed Jan 02 2013 Erik van Pienbroek erik-fed...@vanpienbroek.nl - 0.9.9-2 - Rebuilt against mingw-icu 49 * Mon Dec 24 2012 Erik van Pienbroek epien...@fedoraproject.org - 0.9.9-1 - Update to 0.9.9 - Fix compatibility with WinXP (FreeDesktop Bug #55494) mingw-headers-2.0.999-0.16.trunk.20130105.fc19
Re: [Mingw-w64-public] Export symbols with aliases with 64bit
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_64-w64-mingw32-windres glib.rc glib-win32-res.o CCLD libglib-2.0.la Cannot export g_dir_open: symbol not defined Cannot export g_dir_read_name: symbol not defined Did you already try to remove the glib.def file? When you do this, the file should get re-generated automatically. Its contents are supposed to be different between the win32 and win64 targets (because of historical reasons, upstream needs to retain binary API compatibility). -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for November 13 2012
This is a report for the 20121113 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 20121110 trunk snapshot * binutils 2.22.52.0.4 * gcc 4.7.2 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20121113 Total packages: 150 Number of failed packages: 1 Number of succeeded packages: 149 Number of added packages since previous mass rebuild: 0 Time needed to perform mass rebuild: 30 hours, 19 minutes, 3 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20121106 Total packages: 150 Number of failed packages: 3 Number of succeeded packages: 147 === 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 to 20121110 snapshot * Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.14.trunk.20121109 - Update to 20121109 snapshot mingw-filesystem-96-2.fc19 --- * Sat Nov 10 2012 Kalev Lember kalevlem...@gmail.com - 96-2 - Add provides for mscoree.dll and regenerate the standard-dlls file mingw-glib2-2.35.1-1.fc19 -- * Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.35.1-1 - Update to 2.35.1 mingw-gnutls-2.12.21-1.fc19 * Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.12.21-1 - Update to 2.12.21 mingw-gtk3-3.7.0-1.fc19 * Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 3.7.0-1 - Update to 3.7.0 mingw-headers-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 to 20121110 snapshot - Fixes build issue with DirectWrite support in mingw-qt5-qtbase * Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.0.999-0.14.trunk.20121109 - Update to 20121109 snapshot mingw-libtasn1-2.14-1.fc19 --- * Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.14-1 - Update to 2.14 mingw-openssl-1.0.1c-1.fc19 * Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 1.0.1c-1 - Update to 1.0.1c - Synced patches with native openssl-1.0.1c-7.fc19 mingw-qt-4.8.3-3.fc19 -- * Sun Nov 04 2012 Erik van Pienbroek epien...@fedoraproject.org - 4.8.3-3 - Don't automatically strip debugging symbols from binaries created using qmake as we've got RPM wrapper strips to automatically split off debugging symbols to a separate debuginfo subpackage - Make sure linking against the static QtUiTools library works out-of-the-box mingw-qt5-qt3d-5.0.0-0.2.beta1.git2012.e4d3ccac.fc19 - * Sun Nov 11 2012 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.2.beta1.git2012.e4d3ccac - Update to 2012 snapshot (rev e4d3ccac) - Rebuild against latest mingw-qt5-qtbase - Dropped pkg-config rename hack as it's unneeded now mingw-qt5-qtactiveqt-5.0.0-0.2.beta1.git2012.435fac3b.fc19 --- * Sun Nov 11 2012 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.2.beta1.git2012.435fac3b - Update to 2012 snapshot (rev 4cbcad7f) - Rebuild against latest mingw-qt5-qtbase mingw-qt5-qtbase-5.0.0-0.13.beta1.git20121110.d725239c.fc19 * Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.13.beta1.git20121110.d725239c - Update to 20121110 snapshot (rev d725239c) - Dropped the configure argument -qtlibinfix 5 as upstream has resolved the file conflicts with Qt4 properly now - Added several missing flags to the mkspecs profiles - Dropped the pkg-config file renames as they're not needed any more - Dropped two obsolete patches * Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.12.beta1.git20121103.ccc4fbdf - Update to 20121103 snapshot (rev ccc4fbdf) - Use -std=c++11 instead of -std=c++0x as the latter is deprecated in gcc 4.7 - Added DirectWrite support - Added Angle support mingw-qt5-qtconnectivity-5.0.0-0.2.beta1.git20121112.63139e83.fc19 --- * Mon Nov 12 2012 Erik van Pienbroek epien...@fedoraproject.org - 5.0.0-0.2.beta1.git20121112.63139e83 - Update to 20121112 snapshot (rev 63139e83) - Rebuild against latest mingw-qt5-qtbase - Dropped pkg-config rename hack as it's
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
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 can be run fully automatic and which can create a report about the results. An initial mass rebuild report was just sent to the fedora-mingw mailing list, but if you guys here are interested in it as well I can also forward it to this list in the future. The report can be found at http://lists.fedoraproject.org/pipermail/mingw/2012-November/005884.html The next report (which I expect to generate in a couple of days) will also include a comparison to the previous mass rebuild (i.e. which packages failed to build but succeeded during the previous mass rebuild), a list of all newly added packages (if any) and a list of all changes which were applied in the Fedora MinGW packages (including updates to the mingw-w64 toolchain). An example for such a complete report can be found at http://fpaste.org/1kuz/ Kind regards, Erik van Pienbroek -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
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 and hopefully it should
not affect any builds.
Yes, we also provide various large C++ libraries, like for example
boost, Qt4, Qt5, wine-gecko and wxWidgets. For the complete list see
https://admin.fedoraproject.org/pkgdb/acls/list/?searchwords=mingw-*
(Qt5 isn't yet on that list as those packages are still under review,
but I can already pull them in for local mass rebuilds)
I have a patch that makes C++11 std::to_{w,}string work, it's working
right now, I'm just not sure if there are any bad side effects, which is
where C++ library builds come into play.
Right now, patch is waiting for final OK from Kai, I'll ping again when
the patch makes it in.
Okay, Qt5 is built using C++11 by default, so we can use that to test
your patch
--
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-and-make-money-coding-fast/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
Kai Tietz schreef op wo 24-10-2012 om 21:19 [+0200]: Hello everybody, I want to raise this discussion on public mailing-list, as mingw-w64's release-cycle might be also of interest to some of our users. Right now we do the major-release by gut feeling with a background plan about features new version shall include. Now I got the request to do major release like some other ventures - eg gcc, binutils - after a fixed time-line. For example if we would decide for a one-year release-cycle, it would Mean that we work about 6 - 8 months on new features, then we switch to stabelizing phase for 3 months, and then doing major-version branching and doing just bug-fixing on that branch. Another approach would be to do branching only if we are feature-complete for one version. That of course means we should switch from gut-feeling to more detailed feature-plan. So I would like to get your opinion. You might have complete different opinion about planning mingw-w64's release-cycles, so don't hesitate to tell us what you think about this subject. Hi, Before I start I would like to point out that the points mentioned below aren't meant as criticism, but they are areas which I think can potentially be improved. For the TL;DR variant, see the bottom of this mail for my conclusion From my packager/distributor point of view I would like to vouch for the release-early-release-often strategy. This means more frequent releases. Version 2.0 of mingw-w64 was already released over a year ago. In the past year the v2 branch has seen several backports and several releases. However, the difficult thing is that these new releases aren't announced on the website or on the mailing list at all. This makes it hard for packagers and other users to find out if a new version of mingw-w64 is available. Also, if people want to know what has changed between releases then they have are forced to check the SVN repo history. Another thing that I consider is missing are unstable releases. In Fedora RPM packages always need to have a version number and a release number. For mingw-w64 releases based on the v2 branch this is simple (for example: version=2.0.7, release=1). However as there are no unstable mingw-w64 releases being created for the trunk branch (and we in Fedora want to provide packages based on the trunk branch) we had to invent our own version number in Fedora. We want to make sure that whenever users want to update from the current trunk version to the final 3.0 release (once it will be released) that RPM thinks that the final 3.0 release is more recent than the current trunk version and allows the update. Because of this reason we're currently building our mingw-w64 packages using version=2.0.999 and release=0.1.trunk.20121023. With this pattern users can see that we're using a trunk snapshot dated 20121023 and the upgrade path will work when mingw-w64 version 3.0 will be released. In the end this custom version number is confusing to end-users as on the mingw-w64 website there are no references to version 2.0.999. One way to solve this issue is to publish unstable releases from time to time. To sum it up I would like to propose the following: * Publish unstable releases (from the trunk branch) periodically (this can be time based) * Once the trunk has reached a certain level of stability/new set of features branch it and make a stable release * When regressions are detected in a stable branch publish a new stable release * Give more visibility to new releases on the website and the mailing list and include a global outline of the most important changes A potential versioning scheme for this could be the GNOME one. They're using uneven major version numbers to mark unstable releases (like 3.5.x) 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. 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-and-make-money-coding-fast/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
Jacek Caban schreef op do 25-10-2012 om 14:51 [+0200]: A few more words about ensuring stability: We mostly know what risky changes have been made and we occasionally hear back from users when something breaks. I myself would know quickly if something really bad happened. I do Mozilla code base builds as cron nightly job and update mingw-w64 every few days on that box. It exercises headers and crt pretty heavily, so it's quite a compelling test. Now, if we had a few such projects (eg. regular Qt builds) that we can easily ensure to be working correctly before each release, that's a pretty good test case. Buildbot would be great for that, but so would be active users/developers that would test builds on regular basis, or at least after tagging for RC. Same for packagers, if it could be coordinated with them to ensure RC works for them, that's probably enough for release. Perhaps I can help in this area. In Fedora we currently have over 125 different mingw packages and we are frequently pushing updated mingw-w64 trunk snapshots to the Fedora development branch. 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. This script could then be run periodically (say once every week) so regressions can be spotted relatively soon. For this I need to find one or more machines where this script can be executed 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 to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
