| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This contains a few hacks very specific to Qt's buildsystem. These can be
reverted once we split the build between native and target builds.
Qt's build contains a circular dependency when not using a system zlib.
By far the easiest fix is to switch to a system zlib, rather than Qt's own.
However, that confuses Qt's cross build which assumes that when using a system
zlib, it should also find a system (native) zlib for native tools. The build
breaks if that zlib is not present.
To solve this:
1. Always use a system zlib rather than the one provided by qt
2. Set force_bootstrap, which instructs the build tools to be built as though
we're cross-compiling (build != target)
3. For build tools, use qt's internal zlib so that a native zlib is not
required.
Step 3 means that if any zlib headers are found by the native build, it will
confuse Qt's internal zlib build. So we also need to make sure that the target
headers/libs aren't found. To do so, specify that our
cflags/cxxflags/cppflags/ldflags only apply for non-host builds.
|
|
qt5.7 changed the location of some of its symbols, creating a circular
dependency in Qt5Core. Rather than trying to fix that up, build our own zlib
rather than having it built for us.
|
|
This also fixes the native osx build.
|
|
Their buildsystem insists on using the installed ltranslate, but gets confused
about how to find it. Since we manually control the build order, just drop the
dependency.
|
|
|
|
|
|
|
|
|
|
clang: 3.7.1
cctools: 877.8
ld64: 253.9
|
|
|
|
All trusty compilers work ok with this now, and it shaves a few minutes off of
build time
|
|
Checksums were being verified after download, but not again before extraction
|
|
Remove sed-based qt PIDLIST_ABSOLUTE workaround, replace by a patch that
works for both old (such as used by Travis and Ubuntu Precise) and new
mingw (Ubuntu Trusty).
|
|
|
|
|
|
Helps ease of reading and comparison. Removed some duplicates.
|
|
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
|
|
|
|
Fixes default hidden symbol visibility for our linux->osx cross build. Without
this change, the check for working -fvisibility=hidden fails, and all symbols
are visible by default.
Ugly as this is, it's just a simple find/replace to fix a bug in Qt's configure.
They assume in an "XPLATFORM_MAC" block that the builder is capable of running
osx programs. This should be "BUILD_ON_MAC" instead.
|
|
qt needs to be rebuilt for travis. The previous commit should help ensure that
this won't need to be done again.
|
|
This means it also needs to honor our flags, so patch them in as necessary.
|
|
This backports the relevant parts of:
https://codereview.qt-project.org/#/c/82689/
|
|
See the README's in depends for documentation
|
