These plugins can't be used on Android, but they are built, installed
and also bundled into every .apk file.
Change-Id: I3326c913282af5bd43e1c732de9ae2f255711414
Reviewed-by: Christian Stromme <christian.stromme@qt.io>
FreeBSD uses gcc as the default compiler until FreeBSD 10 where it was
switched to clang for the whole system. Choose freebsd-clang
for any system release > 10, otherwise choose freebsd-g++ by default.
Change-Id: I2bf38aa027453c25ed2a29d587c2962ded5fcd4a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Qt 3/4 had NIS configure options and tests for NIS defines,
those were used in QPrintDialog at the time to support
NIS-printers. As the implementation went away a long time ago
and no NIS featueres are implemented anywhere in Qt, the
configure options and config.tests for NIS can be removed.
Change-Id: Ie920e6a422540bf938623265b6ee68c793aeff84
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
FreeBSD 9.3 is still supported and uses gcc as the default
compiler, therefore FreeBSD ports require patching the mkspecs
back. To avoid patching, move the mkspecs back to the right
place and adapt the path in the qmake.conf/qplatformdefs.h
[ChangeLog][FreeBSD] The freebsd-g++ mkspec was moved back and no
longer requires the "unsupported/" prefix, matching the FreeBSD
ports tree, as FreeBSD 9.3 still defaults to using GCC. Users of
GCC that did not previously use the ports patch will need to adapt their
build scripts and drop the "unsupported/" prefix.
Change-Id: Ideda4a33cccf5381000f6f50b6ae92a5c24ba9d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some platforms (e.g. FreeBSD) do not have libdl, but dlopen and related
functions are part of libc. So first check for dlopen in libc, and only
if that fails, look for it in libdl.
Task-number: QTBUG-52951
Change-Id: I65a8ed18fce157da32f4e1ffeba30d7513385a8f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
release_tools is not set in pure release builds - in fact, we complain
if it is.
Change-Id: Ifac73c0ef6f8967155b63f7fc9c9ce9de1acf337
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Let the user know that configure's switch from -no-freetype/-qt-freetype
to -system-freetype when -fontconfig is used is expected.
Task-number: QTBUG-35886
Change-Id: I95daaeffb0878bb785149f314096405a5c0fdc7a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The "checking for xxx... [yes|no]" is chosen so that it matches exactly
what GNU Autoconf does. That way, any tools that parse the output will
have less trouble.
This feature is useful for us when debugging a build, as not all checks
produce output in the configure summary.
Change-Id: Id75834dab9ed466e94c7ffff14456edb646a1ced
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this was meant to be part of d8be8110a, as qmake is obviously also a
bootstrapped tool.
-I/-L/-F/-l/-fw already had no effect on qmake.
Change-Id: I5095742ef5401558cc4432e7a774d0851d417bb0
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Have configure add a "CONFIG -= precompile_header" to qmodule.pri when
-no-pch is specified. Ensures that Qt is built without precompiled
headers (as requested) even if allowing precompiled header use is the
default for the toolchain.
Parallels changes to Windows configure.
Task-number: QTBUG-11545
Change-Id: Iab4021e74c4e9978770e917dff97b976c449dd8b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
[ChangeLog][Important Behavior Changes] Support for DirectFB is no
longer enabled by default, due to lack of development in upstream. To
re-enable the platform plugin, pass the -directfb option to configure. If
there is no interest in this platform, the support will be deprecated in
Qt 5.7 and will be removed in Qt 5.8.
See: http://lists.qt-project.org/pipermail/development/2016-March/025273.html
Change-Id: Icaa7fb2a490246bda156ffff143c62515a5f575b
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
There was a small logic error in the code selecting the debug/release
C(XX)_FLAGS used when compiling qmake, that could lead to us not
specifying any flags at all.
Change-Id: I5d3c44367d535a17570e3602029b84a02706d624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes the -separate-debug-info configure optional functional, which
generates dSYM debug info bundles for Qt libraries on Apple platforms.
Task-number: QTBUG-37952
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Ia247674740bf450130a15db926df07fa9007e2ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
...instead of overwriting when building qmake for windows.
Change-Id: I89eb33439b03a0ad33d006d12c9896c87d271c4f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
it is important that the flags coming from the current qt build appear
first, as otherwise a pre-existing qt installation may interfere with
the build.
the windows configure does not have any of this magic to start with.
Task-number: QTBUG-6351
Change-Id: Iacc1d9b5aa9eed9a5f0513baef9f6c6ffcef0735
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
now that we rely on consistently sane runpath semantics everywhere
(--enable-new-dtags on linux; the default elsewhere), there is no use
in forcing our runpath downstream: our libraries will find their
dependencies due to their embedded runpath.
this does not affect qt.prf adding qt's own library path to the user
projects' runpath.
this effectively reverts 42a7eb8df6, and some more.
Change-Id: If7af7be7b7a894bebb9b146ccb0035452223c7ac
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
-ldl option was used unconditionally while libdl is not supported
when libc is static.
Add build test to configure which checks if libdl is supported.
QMAKE_LIBS_DYNLOAD in "src/corelib/plugin/plugin.pri" is now used only
if libdl is available.
qt_linux_find_symbol_sys from qlibrary_unix is now used only if
QT_NO_DYNAMIC_LIBRARY is not defined.
Initially reported by Buildroot autobuilder here:
http://autobuild.buildroot.net/results/a85/a85a1839a45fb6102e53131ecc8f6dadf92bcdc2
Change-Id: I0397472456efdc4f3ab5f24d01253bee8048a9d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Modern FreeBSD doesn't come with GCC by default anymore and doesn't even
provide the "gcc" or "g++" falback that OS X does. So there's no point
in keeping the freebsd-clang mkspec in unsupported/ since it's the only
one that works, or keeping the freebsd-g++* ones outside, as they won't
compile.
I'm not removing the GCC mkspecs because you can still install GCC from
the ports tree.
[ChangeLog][FreeBSD] The "freebsd-clang" mkspec is no longer in the
unsupported/ subdir. If you have scripts you use to build Qt, you'll need to
update them to say -platform freebsd-clang or remove the -platform argument.
Change-Id: I7a9e11d7b64a4cc78e24ffff142dfc11d3aabb1e
Reviewed-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
'local' is treated as a command, so its arguments need to be quoted,
unlike in a real variable assignment.
amends 4b557751e.
Change-Id: I5a4c929e52e2344a6129c8e9dd4c0c80cd408ff0
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The C++ standard says it must, but some badly-configured toolchains seem
to be lacking support.
In particular, for some 32-bit platforms without native support for
them, GCC implements 64-bit atomics via out-of-line functions in
libatomic. If that library is missing... well, then std::atomic 64-bit
doesn't work and we mustn't try to use it.
This was found when trying to compile Qt 5.6 for MIPS 32-bit:
Linking library libQt5Core.so.5.6.0
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:500: undefined reference to `__atomic_load_8'
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::store(unsigned long long, std::memory_order)':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'
Yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8274
Change-Id: I42e7ef1a481840699a8dffff140224d6614e5c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3d7586b760)
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
[ChangeLog][Platform Specific Changes][OS X] Configure with -no-rpath
will now yield Qt dynamic libraries and frameworks with an absolute
install name (based in -libdir).
OS X package managers like Homebrew install Qt in a fixed location. This
change simplifies deployment for such package managers and is consistent
with the default expectation on Apple platforms for libraries with a
fixed location to also have absolute install names.
While a relocatable installation (the default) also works in this
scenario, it requires all software that depends on Qt to be aware of
this and to embed a suitable RPATH into application binaries (which is
not automatic for non-qmake builds). This might not be true for some
select fallback search locations, but as package managers on OS X tend
not to use those, embedding an RPATH becomes practically mandatory. In a
default Homebrew installation, Qt is configured such that the frameworks
end up in /usr/local/Cellar/qt5/<version>/lib and that will be later
symlinked to /usr/local/opt/qt5/lib, both of which are not searched by
the dynamic linker by default.
Task-number: QTBUG-48958
Change-Id: I4395df98771e06a2ce8a293d11dc755bdc50757f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The part of qmodule.pri that is supposed to set QT_CPU_FEATURES ends up
missing in the output.
Change-Id: I30f3dbad5ac22d32e25d63037980dac370adc4ea
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
instead of building host tools always in debug mode, follow the overall
build type, and provide an option to override it.
this supersedes the pre-existing -optimized-qmake option.
however, that option never existed in the windows configure, and this
legacy continues as far as qmake is concerned (msvc builds of qmake are
always somewhat optimized, but not mingw builds).
Change-Id: I42e7ef1a481840699a8dffff13fec2626af19cc6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Windows' configure.exe supports -ltcg since several years,
this patch adds -ltcg to Unix's configure script.
Change-Id: I3f39086c67c3f4cacd252f63de30e3cfc4aa22bb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
A wayland compositor on i.MX6 needs to create the wl_display
before creating the EGL display. This wl_display then needs to be
exposed so that QWaylandCompositor can use it.
Change-Id: Id60f6dd2fbba05140ca0671da6f17dbc2ecce3a3
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
This commit removes the legacy ptrsize check, which was deficient
because it did not work for multiarch systems (when we supported fat
OS X binaries) and did not work for bootstrap builds because the size
might be different when cross-compiling.
Instead, let's rely on the predefined preprocessor macros to detect
correctly. As a nice side-effect, this fixes 64-bit Android builds
cross-compiled from Windows.
Task-number: QTBUG-48932
Change-Id: I1d0f78915b5942aab07cffff140f9a52b9342f23
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
We'll remove it in Qt 5.7, so people ought to be notified now.
Change-Id: Ib056b47dde3341ef9a52ffff13ef6caa91757a9f
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Redirecting on every command is wasteful.
Change-Id: I42e7ef1a481840699a8dffff1404fa0602805d1b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It's easier to parse than qglobal.h. The objective is actually to have
macros with parts of the version number, so the major or minor numbers
could be used in other preprocessor macros.
Change-Id: I42e7ef1a481840699a8dffff1404eda1dd5c308d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
KMS is no longer a platform plugin so the relevant leftover bits are
now removed.
As the introduction of the EGLDevice-based backend for eglfs shows,
using DRM/KMS is not tied to GBM, separate buffer management
approaches, like EGLStreams, work fine as well. Therefore separate KMS
from GBM and remove the EGL and GLES dependency in the tests - this
way there is nothing preventing us from using GBM without GL for
example.
Change-Id: Id7ebe172b44b315f9a637892237d2bb62d99aed2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
For now we pick one crtc and find the corresponding layer. If this is
not desired, set QT_QPA_EGLFS_LAYER_INDEX to override the layer to be
used. Enable qt.qpa.eglfs.kms to get logs about the available layers.
Change-Id: I762783f960739e32966c8cde17d8f55fbe40091f
Done-with: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources
into the same pile, passing them on to the same compiler as for C++ (CXX),
with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as
variants of the C and C++ languages separately, so that Objective-C
sources are built with CC and with CFLAGS, and Objective-C++ sources
with CXX, and CXXFLAGS.
This lets us remove a lot of duplicated flags and definitions from the
QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched
the C++ equivalent. The remaining Objective-C/C++ flags are added to
CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in
C/C++ mode. This matches Xcode, which also doesn't have a separate build
setting for Objective-C/C++ flags.
The Makefile qmake generator has been rewritten to support Objective-C/C++
fully, by not assuming that we're just iterating over the C and C++
extensions when dealing with compilation rules, precompiled headers, etc.
There's some duplicated logic in this code, as inherent by qmake's already
duplicated code paths, but this can be cleaned up when C++11 support is
mandatory and we can use lambda functions.
Task-number: QTBUG-36575
Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
[ChangeLog][QtDBus] The QtDBus library now links directly to the
libdbus-1 system library if it was detected at configure time. To force
linking to the library, pass option -dbus-linked to configure; to force
dynamically loading at runtime, use -dbus-runtime.
Task-number: QTBUG-14131
Change-Id: Ie33d1f22f85b465ab0ce166b8f17b8491eae1c21
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the purpose is to make build log parsers able to ignore build failures
in verbose configure output.
Change-Id: I01af2e019fd1b055fdfcf6749faeebacb7a39c3f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In addition to the proprietary Mali Linux driver bundle from ARM, there
are a couple of semi open source alternative bundles out in the wild,
which are mostly derivatives from the sunxi-mali bundle.
The non-ARM bundles lacks the proprietary header file fbdev_window.h
which defines the fbdev_window struct. Instead, it has an equivalent
mali_native_window struct in the EGL/eglplatform.h (which in turn is
included by EGL/egl.h).
This change adds an alternative configure test which detects the non-ARM
bundles are used. It also removes the dependency on fbdev_window.h by
defining the structure ourselves, which actually makes the plugin
potentially compilable with *any* EGL SDK.
Change-Id: I78ab4b618e8e9c774c889fe9896105cf2cf4228e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
The C++ standard says it must, but some badly-configured toolchains seem
to be lacking support.
In particular, for some 32-bit platforms without native support for
them, GCC implements 64-bit atomics via out-of-line functions in
libatomic. If that library is missing... well, then std::atomic 64-bit
doesn't work and we mustn't try to use it.
This was found when trying to compile Qt 5.6 for MIPS 32-bit:
Linking library libQt5Core.so.5.6.0
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:500: undefined reference to `__atomic_load_8'
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::store(unsigned long long, std::memory_order)':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'
Yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8274
Change-Id: I42e7ef1a481840699a8dffff140224d6614e5c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ppc/ppc64 and 32-bit x86 have been dead for a while.
consequently, the legacy macx-g++-64 spec was most probably not used.
which in turn meant that NATIVE_64_ARCH was never set (in particular on
windows hosts ...), which means that the android ndk host auto-detection
was effectively broken.
the arch code in mac/default_post.prf was also never triggered, so nuke
it as well.
Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).
Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
As planned for 5.6, QtMultimedia now uses GStreamer 1.0 over
0.10 when available.
This means the binary packages will be based on GStreamer 1.0.
Task-number: QTBUG-47920
Change-Id: I9a18569ff96902116f0f6a759c185a5896f520d5
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
