Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions
2012/1/18 Ozkan Sezer : > On Wed, Jan 18, 2012 at 9:14 AM, niXman wrote: >> Look sched.h and semaphore.h headers. They both are defined macros to >> export. I offered the same patch. >> What my patch does not suit you? >> > > First, I said that I left that patch to others to review and decide. > > Second, and more importantly, I must understand why it does not work > with you: Are you sure that you patched the time.h in your toolchain > installation? And, since you didn't send the preprocessed sources, I > still don't know what is going on on your end. Yesterday I sent a email with an attachment. I do not know why it was not delivered. > > -- > O.S. > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-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] winpthreads doesn't export clock_* functions
2012/1/18 niXman : > 2012/1/18 Ozkan Sezer : >> On Wed, Jan 18, 2012 at 9:14 AM, niXman wrote: >>> Look sched.h and semaphore.h headers. They both are defined macros to >>> export. I offered the same patch. >>> What my patch does not suit you? >>> >> >> First, I said that I left that patch to others to review and decide. >> >> Second, and more importantly, I must understand why it does not work >> with you: Are you sure that you patched the time.h in your toolchain >> installation? And, since you didn't send the preprocessed sources, I >> still don't know what is going on on your end. > Yesterday I sent a email with an attachment. I do not know why it was > not delivered. I can tell you, and you should have received a reply by ML that your mail exceeds size-limit. Maybe pack attachment as gz/bz/zip to reduce it size. It is really no fun to have 305 Kb attachments in ML. Regards, Kai -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-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] winpthreads doesn't export clock_* functions
2012/1/18 Kai Tietz : > 2012/1/18 niXman : >> 2012/1/18 Ozkan Sezer : >>> On Wed, Jan 18, 2012 at 9:14 AM, niXman wrote: Look sched.h and semaphore.h headers. They both are defined macros to export. I offered the same patch. What my patch does not suit you? >>> >>> First, I said that I left that patch to others to review and decide. >>> >>> Second, and more importantly, I must understand why it does not work >>> with you: Are you sure that you patched the time.h in your toolchain >>> installation? And, since you didn't send the preprocessed sources, I >>> still don't know what is going on on your end. >> Yesterday I sent a email with an attachment. I do not know why it was >> not delivered. > > I can tell you, and you should have received a reply by ML that your > mail exceeds size-limit. Maybe pack attachment as gz/bz/zip to reduce > it size. It is really no fun to have 305 Kb attachments in ML. I pack it with 7z. niXman. > > Regards, > Kai > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-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] winpthreads doesn't export clock_* functions
2012/1/18 niXman : > 2012/1/18 Kai Tietz : >> 2012/1/18 niXman : >>> 2012/1/18 Ozkan Sezer : On Wed, Jan 18, 2012 at 9:14 AM, niXman wrote: > Look sched.h and semaphore.h headers. They both are defined macros to > export. I offered the same patch. > What my patch does not suit you? > First, I said that I left that patch to others to review and decide. Second, and more importantly, I must understand why it does not work with you: Are you sure that you patched the time.h in your toolchain installation? And, since you didn't send the preprocessed sources, I still don't know what is going on on your end. >>> Yesterday I sent a email with an attachment. I do not know why it was >>> not delivered. >> >> I can tell you, and you should have received a reply by ML that your >> mail exceeds size-limit. Maybe pack attachment as gz/bz/zip to reduce >> it size. It is really no fun to have 305 Kb attachments in ML. > I pack it with 7z. > > niXman. I just checked ML and there is no message pending by you. Kai -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-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] winpthreads doesn't export clock_* functions
>> Look sched.h and semaphore.h headers. They both are defined macros to >> export. I offered the same patch. >> What my patch does not suit you? >> > > First, I said that I left that patch to others to review and decide. > > Second, and more importantly, I must understand why it does not work > with you: Are you sure that you patched the time.h in your toolchain > installation? And, since you didn't send the preprocessed sources, I > still don't know what is going on on your end. Yesterday I sent a email with an attachment. I do not know why it was not delivered. >> It was delivered and I made the time.h patch using the information from it. However I need a new one: preprocessed sources after you did the following: - applied the time.h patch to time.h in your toolchain installation - did a make distclean in winpthreads - reconfigured it and rebuilt it -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-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 gcc 4.7 and mingw-w64 trunk mass rebuild on Fedora
Hi, As the Fedora project recently decided to introduce a recent gcc 4.7 snapshot and perform a mass rebuild of all packages using it I decided to perform a mass rebuild as well for all cross compiled packages which are currently in the Fedora mingw-w64 testing repository (https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework) For this mass rebuild I've used the following toolchain releases: binutils: 2.22.51 (20120112 snapshot) gcc: 4.7 (20120106 snapshot) mingw-w64: trunk (20120112 snapshot with r4737 and r4738 to fix wcslen) Support for the experimental winpthreads wasn't included in this mass rebuild. A patched copy of pthreads was used to enable libgomp support in GCC. The complete list of packages which were rebuild can be found at http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%20Framework/ Here are the statistics of this mass rebuild: Total number of packages: 142 Successful builds: 131 Failed builds: 11 The following packages failed to build: boost-1.47.0 dbus-1.4.8 gettext-0.18.1.1 glib2-2.31.8 kdelibs-4.7.97 libgpg-error-1.10 libvirt-0.9.8 OpenSceneGraph-2.8.3 qpid-cpp-0.12 qt-4.8.0 webkitgtk-1.6.1 Here are the details of the individual failures - boost-1.47.0: In file included from /builddir/build/BUILD/boost_1_47_0/boost/thread/detail/platform.hpp:17:0, from /builddir/build/BUILD/boost_1_47_0/boost/thread/thread.hpp:12, from /builddir/build/BUILD/boost_1_47_0/libs/thread/src/win32/thread.cpp:10: /builddir/build/BUILD/boost_1_47_0/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" This seems to be caused by a change in behavior in gcc 4.7 wrt thread support. See https://svn.boost.org/trac/boost/ticket/6165 for more details. A workaround is available in that ticket to fix the failure. Thomas Sailer (the Fedora package maintainer of the mingw32-boost package) already applied some changes which are required to build boost using gcc 4.7 and he updated to boost-1.48.0 at the same time. I already forward-ported these changes to the boost package in the mingw-w64 testing repository so the package builds fine now. - dbus-1.4.8: ../../dbus/dbus-sysdeps.c: In function '_dbus_error_from_errno': ../../dbus/dbus-sysdeps.c:916:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:912:5: error: previously used here ../../dbus/dbus-sysdeps.c:924:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:920:5: error: previously used here ../../dbus/dbus-sysdeps.c:956:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:952:5: error: previously used here ../../dbus/dbus-sysdeps.c:964:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:960:5: error: previously used here ../../dbus/dbus-sysdeps.c:972:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:968:5: error: previously used here ../../dbus/dbus-sysdeps.c:980:5: error: duplicate case value ../../dbus/dbus-sysdeps.c:976:5: error: previously used here The lines mentioned contain the contents: dbus-sysdeps.c:912 - case EPROTONOSUPPORT: dbus-sysdeps.c:916 - case WSAEPROTONOSUPPORT: dbus-sysdeps.c:920 - case EAFNOSUPPORT: dbus-sysdeps.c:924 - case WSAEAFNOSUPPORT: dbus-sysdeps.c:952 - case ECONNREFUSED: dbus-sysdeps.c:956 - case WSAECONNREFUSED: dbus-sysdeps.c:960 - case ETIMEDOUT: dbus-sysdeps.c:964 - case WSAETIMEDOUT: dbus-sysdeps.c:968 - case ENETUNREACH: dbus-sysdeps.c:972 - case WSAENETUNREACH: dbus-sysdeps.c:976 - case EADDRINUSE: dbus-sysdeps.c:980 - case WSAEADDRINUSE: It looks like a change was done in the mingw-w64 headers recently which makes various WSA error code defines contain exactly the same value as their errno counterparts. I don't know if this is the correct change or not, but it does break compilation of packages. - gettext-0.18.1.1: ../../../gettext-tools/gnulib-lib/vsnprintf.c:40:1: error: redefinition of 'vsnprintf' In file included from ./stdio.h:35:0, from ../../../gettext-tools/gnulib-lib/vsnprintf.c:24: /usr/i686-w64-mingw32/sys-root/mingw/include/stdio.h:545:7: note: previous definition of 'vsnprintf' was here make[3]: *** [vsnprintf.lo] Error 1 Apparently the gettext build scripts think that there's no vsnprintf on win32/win64 and therefore tries to build its own implementation. Upon further investigation I think I've found the cause for this false assumption. Here's a snippet from the configure script config.log: configure:43169: checking for vsnprintf configure:43169: i686-w64-mingw32-gcc -std=gnu99 -o conftest.exe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -I/usr/i686-w64-mingw32/sys-root/mingw/include -Wl,--disable-auto-import conftest.c >&5 conftest.c:336:6: warning: conflicting types for built-in function 'vsnprintf' [enabled by default] /tmp/ccvXYksQ.o: In function `main': /home/erik/fedora_cross/mingw-gettext/gettext-0.18.1.1/build_win32/gettext-tools/conftest.c:347: undefined reference
Re: [Mingw-w64-public] Results of gcc 4.7 and mingw-w64 trunk mass rebuild on Fedora
Hello Erik! One data point: I have successfully built qt 4.8. (See inline comments, below.) On Wed, Jan 18, 2012 at 6:24 PM, Erik van Pienbroek wrote: > Hi, > > As the Fedora project recently decided to introduce a recent gcc 4.7 > snapshot and perform a mass rebuild of all packages using it I decided > to perform a mass rebuild as well for all cross compiled packages... > For this mass rebuild I've used the following toolchain releases: > binutils: 2.22.51 (20120112 snapshot) > gcc: 4.7 (20120106 snapshot) > mingw-w64: trunk (20120112 snapshot with r4737 and r4738 to fix wcslen) > ... > kdelibs-4.7.97: > > Failed to build because I didn't manage to get qt-4.8.0 compiled > using gcc 4.7. See below for details about the qt failure > ... > > qt-4.8.0: I have successfully built qt-4.8 natively with mingw-w64 4.7 (as have others), specifically: 4.8.0-rc1, from qt-everywhere-opensource-src-4.8.0-rc1.zip g++ (GCC) 4.7.0 20110829 (experimental), from x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z > In file included > from > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qbuiltinatomictypes_p.h:55:0, > from > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qbuiltinatomictypes.cpp:45: > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qatomiccasterlocators_p.h:570:46: > error: 'virtual QPatternist::AtomicTypeVisitorResult::Ptr > QPatternist::ToDerivedIntegerCasterLocator::visit(const > QPatternist::BooleanType*, const QPatternist::SourceLocationReflection*) > const' cannot be overloaded > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qatomiccasterlocators_p.h:295:46: > error: with 'virtual QPatternist::AtomicTypeVisitorResult::Ptr > QPatternist::ToIntegerCasterLocator::visit(const QPatternist::BooleanType*, > const QPatternist::SourceLocationReflection*) const' > /builddir/build/BUILD/qt-everywhere-opensource-src-4.8.0/src/xmlpatterns/type/qatomiccasterlocators_p.h:577:46: > error: 'virtual QPatternist::AtomicTypeVisitorResult::Ptr > QPatternist::ToDerivedIntegerCasterLocator::visit(const > QPatternist::StringType*, const QPatternist::SourceLocationReflection*) > const' cannot be overloaded > > > This seems to be caused a change in behavior in gcc 4.7. Somebody else > also experienced this compiler error while building a native qt using > gcc 4.7: http://developer.qt.nokia.com/forums/viewthread/12606 > The native qt package in Fedora also currently fails to build due to > this issue > (http://koji.fedoraproject.org/koji/getfile?taskID=3635149&name=build.log&offset=-4000) > so I guess upstream will come up with a solution soon. I did not see the sort of errors you are reporting. I don't know whether this information helps you, as we are doing somewhat different things. However, at a crude level at least, qt-4.8 with mingw-w64 g++ 4.7 does (or can be made to) work. > ... > Could anybody shed some light about the issues which were > encountered during this mass rebuild? Especially the errno > codes looks like a serious issue to me. If there is anything else useful I can tell you, feel free to ask. > Kind regards, > > Erik van Pienbroek Good luck. K. Frank -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
