| Age | Commit message (Collapse) | Author |
|---|
|
f509e3b8ce0c5652e85ce26545f7ed94689f46ab doc: remove line numbers from qt package links (fanquake)
1bb1661a402de573840d2089fc27f797c8b64f15 doc: fix typo in bitcoin_qt.m4 comment (fanquake)
0aeb98ac1fc5cf62b4516896fa93ac97faafd736 build: remove jpeg lib check from bitcoin_qt.m4 (fanquake)
98a64bd296b06ea0dddf91b08134871158609bbf build: disable libjpeg in qt (fanquake)
Pull request description:
When gitian building on Windows I'm seeing:
```bash
checking for Qt 5... yes
checking for > Qt 5.7... yes
checking for main in -limm32... yes
checking for main in -lz ... yes
checking for library containing jpeg_create_decompress ... configure: WARNING: libjpeg not found. Assuming qt has it built-in
no
checking for library containing png_error ... -lqtlibpng
checking for library containing pcre2_match_16... -lqtpcre2
checking for library containing hb_ot_tags_from_script ... -lqtharfbuzz
```
We are passing `-qt-libjpeg` to Qt:
https://github.com/bitcoin/bitcoin/blob/e6e99d4f757f2e5052f0cc68951c75e91e4753e3/depends/packages/qt.mk#L66
but I dont think we are doing anything with `jpeg` related regardless?
ACKs for top commit:
laanwj:
ACK f509e3b8ce0c5652e85ce26545f7ed94689f46ab
promag:
ACK f509e3b8ce0c5652e85ce26545f7ed94689f46ab.
Tree-SHA512: 61ea20c11df11b9d426644df9a01aac12b76897003121a283fc784a8c30e9b5ad34c9805069fec20926f7aa279e59528e2e13697a944a22760c3acb6366fffbe
|
|
|
|
|
|
We can actually patch QT to remove its dependency on libX11's headers.
It turns it this wasn't that hard.
|
|
libXext was only needed (as a library) by QT when it was using
XLib/libX11 (as a library), now that we're building QT without
XLib/libX11, we can safely remove libXext.
|
|
Previously, in 683b7d7a3fc1b9240333faf3d04497aa61583016 and
0e752637a26cf75187864a466db9a92540a2d3c8, we accidentally broke QT's
ability to pick up Xlib thru the config.gui.tests.xlib configuration
test, which also means that config.gui.libraries.xcb_xlib wasn't run.
This resulted in a QT build that was implicitly -no-xcb-lib and
-no-feature-xlib.
This is actually a desired behaviour, as it means less required shared
objects for our final bitcoin-qt binary. Specifically, it eliminated the
libX11-xcb.so.1 and libX11.so.6 requirements.
In this commit, we explicitly build without Xlib. We should continue to
track upstream ticket https://bugreports.qt.io/browse/QTBUG-61452 which
talks about adding a -no-xlib (non-hidden) flag instead of the
-no-feature-xlib (hidden) flag.
|
|
|
|
|
|
Let a man use his builtins if he wants to! Also, removes the unnecessary
assumption that pwd lives under /bin/pwd.
|
|
For normal users, --no-same-owner is default, but not so for root, where
it is assumed that root can change ownership willy-nilly. This is not
the case for privilege-limited container environments where we gaslight
the process into thinking it's root.
|
|
|
|
|
|
We may eventually want to break out harfbuzz and build it in depends, but
for now just ensure that runtime dependencies don't depend on whether or not
harfbuzz was present on the builder.
|
|
A few years ago, libfreetype introduced FT_Get_Font_Format() as an alias for
FT_Get_X11_Font_Format(), but FT_Get_X11_Font_Format() was kept for abi
backwards-compatibility.
Our qt bump to 5.9 introduced a call to FT_Get_Font_Format(). Replace it with
FT_Get_X11_Font_Format() in order to remain compatibile with older freetype,
which is still used by e.g. Ubuntu Trusty.
|
|
Qt's configure grabs the path to xkb's data root during configure, but the
build changes in 5.8 apparently broke the handling for cross builds. As a
result, the string embedded in the binary depends on whether or not some files
are present in the builder's filesystem.
The "-xkb-config-root" configure setting is intended to allow manual overriding
but it is also broken. See: https://bugreports.qt.io/browse/QTBUG-60005
This has since been fixed upstream, so just hard-code the path for now. We can
drop this patch when we bump to a fixed Qt.
Also, fix the "-qt-xkbcommon-x11" config param which was renamed. This does not
appear to affect build results, presumably because auto-detection is working,
but it does not hurt to be explicit.
|
|
|
|
|
|
6b5506a286 Fix Qt's rcc determinism for depends/gitian (Fuzzbawls)
Pull request description:
With the update to Qt 5.9 having been merged, Qt's `rcc` tool now embeds a file's last modified time in it's output. Since the build system generates temporary files for all locale translations (`*.qm` files) at build time, the resulting `qrc_bitcoin_locale.cpp` file was always being generated in a non-deterministic way.
This is a backport of https://bugreports.qt.io/browse/QTBUG-62511, which is included in Qt versions 5.11+, that allows for an environment variable (`QT_RCC_SOURCE_DATE_OVERRIDE`) to override the behavior described above. This environment variable is in turn set in the gitian descriptors, as that is where determinism is vital for release purposes.
Prior to this, the `qt_libbitcoinqt_a-qrc_bitcoin_locale.o` object file (included into `libbitcoinqt.a`) was returning a different `sha256sum` for each and every build, regardless of file contents change, thus breaking determinism in the resulting binaries.
This should fix #13731
Tree-SHA512: 174017e41f9afc3950ef54a9419de81577ec900db9aec3c78ccd3d879c6aecaaeb944fde0615b933f43e6ca9d7898a27ec071cdd0b91cb772755a3012de96725
|
|
Backport of https://bugreports.qt.io/browse/QTBUG-62511 to resolve
locale determinism during the build process.
|
|
|
|
Some hobbyists are used to using the desktop for interfacing with their
raspberry pi. This commits adds qt to the arm-linux-gnueabihf target.
|
|
|
|
Apply patch from QTBUG-67286
|
|
Depends can now be built with Qt5.9.4 , which is Qt's new long term
support version.
|
|
|
|
|
|
|
|
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
|
