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 ** > > 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 > > > > RPM packaging problem?? This indeed sounds like more strict behavior of RPM > > 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 > > > > Lots of undefined ref to mozilla::TimeStampValue::TimeStampValue and > operators, missing lib? I think this one is also winpthreads related. When building without winpthreads it builds just fine. The configure output shows these messages: For the non-winpthreads build: checking for clock_gettime(CLOCK_MONOTONIC)... no For the winpthreads build: checking for clock_gettime(CLOCK_MONOTONIC)... This causes the non-winpthreads build to compile a file called TimeStamp_windows.cpp and the winpthreads build to compile a file called TimeStamp_posix.cpp Which brings us to the 'make' output from the winpthreads build: i686-w64-mingw32-g++ -mwindows -o TimeStamp_posix.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DNO_NSPR_10_SUPPORT -D_IMPL_NS_COM -I/builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds/../io -I/builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds -I. -I../../dist/include -I/builddir/build/BUILD/mingw-wine-gecko-2.21/wine_gecko-2.21-x86/dist/include/nspr -I/builddir/build/BUILD/mingw-wine-gecko-2.21/wine_gecko-2.21-x86/dist/include/nss -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-invalid-offsetof -Wcast-align -Wno-format -DWINE_GECKO_SRC -fpermissive -fno-exceptions -fno-strict-aliasing -mms-bitfields -mstackrealign -fno-keep-inline-dllexport -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -O -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/TimeStamp_posix.o.pp /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds/TimeStamp_posix.cpp nsWindowsRegKey.cpp /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds/TimeStamp_posix.cpp: In static member function 'static mozilla::TimeStamp mozilla::TimeStamp::Now(bool)': /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds/TimeStamp_posix.cpp:173:32: warning: invalid conversion from 'uint64_t {aka long long unsigned int}' to 'mozilla::TimeStampValue::_SomethingVeryRandomHere*' [-fpermissive] return TimeStamp(ClockTimeNs()); ^ In file included from ../../dist/include/mozilla/TimeStamp.h:22:0, from /builddir/build/BUILD/mingw-wine-gecko-2.21/wine-mozilla-2.21/xpcom/ds/TimeStamp_posix.cpp:18: ../../dist/include/mozilla/TimeStamp_windows.h:31:3: warning: initializing argument 1 of 'mozilla::TimeStampValue::TimeStampValue(mozilla::TimeStampValue::_SomethingVeryRandomHere*)' [-fpermissive] TimeStampValue(_SomethingVeryRandomHere* nullValue); ^ I don't know yet if this permissive warning is the cause of the undefined references, but perhaps it can be investigated by the upstream gecko devs. Regards, Erik van Pienbroek _______________________________________________ mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/mingw
