The recent update of Qt to 5.6.1 breaks build for dependent ports if the processors do not support certain HW features. For instance, when rebuilding vlc with QT5 UI on a Sandy Bridge processor, this happens (all packages built with default OPTIONs): ... Incompatible processor. This Qt build requires the following features: f16c rdrand Aborted. Incompatible processor: missing feature 0x60000000 - f16c. gmake[3]: *** [Makefile:1514: ../modules/plugins.dat] Abort trap gmake[3]: Leaving directory '/wrkdirs/usr/ports/multimedia/vlc/work/vlc-2.2.4/bin' gmake[2]: *** [Makefile:2253: all-recursive] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/multimedia/vlc/work/vlc-2.2.4' gmake[1]: *** [Makefile:2137: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/vlc/work/vlc-2.2.4' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/multimedia/vlc
Over to kde@.
To clarify: was Qt built on the same machine/processor?
Another question: is this an i386 or an amd64 build?
And yet another one: do you have any custom flags in make.conf?
Hi I have a Sandy Bridge myself (i7-3930k -- don't get confused by the 3xxx, it's an exception [1]) and just built vlc with QT5=on [2] -- without any issues. Do you pass any special flags via make.conf? [1] http://ark.intel.com/products/63697/Intel-Core-i7-3930K-Processor-12M-Cache-up-to-3_80-GHz [2] % pkg info vlc | grep QT5 => QT5 : on
ping riggs@
Extra info to answer the questions: - Everything was built in 10-stable amd64 poudriere jail on the same machine (on amd64, for amd64) - All packages were built using default OPTIONs - Only customization: CPUTYPE?=core-avx-i
According to the gcc-4.7 manual [1] * corei7-avx: Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES and PCLMUL instruction set support. * core-avx-i: Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction set support. are you sure you shouldn't be using 'corei7-avx' ? [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
(In reply to Tobias C. Berner from comment #8) You are correct, core-avx-i may use instructions not available on the Sandy Bridge. But why shouldn't I be able to build Ivy Bridge optimised packages (for some new desktop machines) on the (still much faster) Sandy Bridge server around? I would expect to see this build error when using -march=native, but not when setting a concrete target CPU to compile for. I am happily admitting that this is not the most important bug in the world, but still it is one :-)
Reduce importance; this probably affects only a limited number of people with a specific build setup.
(In reply to Thomas Zander from comment #9) > You are correct, core-avx-i may use instructions not available on the Sandy > Bridge. > But why shouldn't I be able to build Ivy Bridge optimised packages (for some > new desktop machines) on the (still much faster) Sandy Bridge server around? > > I would expect to see this build error when using -march=native, but not > when setting a concrete target CPU to compile for. If you're building the packages on a Sandy Bridge using Poudriere, that means Poudriere is installing your Ivy Bridge packages into the jail, and if something needs to run during the build it can end up trying to execute Ivy Bridge-specific instructions. vlc-cache-gen doesn't seem to link directly against Qt, but perhaps when it loads all the plugins to generate modules.dat it ends up loading Qt and failing.
(In reply to Raphael Kubo da Costa from comment #11) So unless Qt libs do not perform some kind of runtime cpu detection, it will continue to throw this error if it runs on a cpu which does not support all features for which support was compiled in. Given that probably the large majority of users won't have a problem with this, and the workaround is not too much of an issue ... if you want to close this with "won't fix", I could live with it. Thanks for joining me in investigating the root cause.
Thanks; I'm closing it as "works as intended" since everything seems to be running according to what's expected.