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>
SecureTransport is now the default SSL backend on OS X.
Users can still choose the OpenSSL backend by passing the -openssl,
-openssl-linked or -no-securetransport option to configure script.
[ChangeLog][Important Behavior Change] Make SecureTransport the default SSL backend on OS X
Change-Id: I7a4edfdb72e63975d6b31435969702f8e86a10f2
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
[ChangeLog][QtCore][Logging] Systems with syslog may now pass -syslog to
configure to send logging output to syslog.
Change-Id: I80d58ee6e70d8deb2409fc666e7e7f2d7f52b8e1
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Also solves a warning printed:
configure: 4200: shift: can't shift that many
Change-Id: Ib306f8f647014b399b87ffff13f295e2cdb7f8d7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The pipe2/dup3/accept4 functions and SOCK_CLOEXEC are quite old nowadays
on Linux. They were introduced on Linux 2.6.28 and glibc 2.10, all from
2008. They were also picked up by uClibc in 2011 and FreeBSD as of
version 10.0. So we no longer need the runtime detection of whether the
feature is available.
Instead, if the libc has support for it, use it unconditionally and fail
at runtime if the syscall isn't implemented.
Change-Id: Ib056b47dde3341ef9a52ffff13efcc39ef8dff7d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There's really no difference between them, other than -force-pkg-config
skipping the check if the tool is even available and printing a warning.
Change-Id: I04cb83c6649ef73866a84032ea46093c4a00ce00
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Otherwise the information is missing from configure's output summary:
EGLFS ................ no
EGLFS i.MX6....... .
EGLFS KMS .......... no
EGLFS Mali .........
EGLFS Raspberry Pi .
EGLFS X11 .......... no
Change-Id: Iee8cbc07c4434ce9b560ffff13cb331778c70261
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The option is named securetransport, not secure-transport.
Change-Id: I5efdde6d751cbc7e9717c6bfe0add93c5dbd2ec9
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This way we can exclude the connection plugins from being compiled
if it's off.
Change-Id: Ic5ea1d35ea9f5929420268a1aefebf0464d8520b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We build our 32 bit Linux packages nowadays on Red Hat 64 bit with
-platform linux-g++-32. Honor this when selecting the right licheck
binary to use.
Change-Id: I08527295bc461c8cdd07e81a10c93a8f010b787d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
