If the `libqt4-dev` package is installed it picks the moc executable
from the system instead of our custom-built one. This results in
compatibility errors.
This commit convinces configure to pick the right one.
3a54ad9 Full translation update (Wladimir J. van der Laan)
9dd5d79 devtools: add a script to fetch and postprocess translations (Wladimir J. van der Laan)
58c01a3 qt: add transifex configuration file (Wladimir J. van der Laan)
202c95c devtools: have symbol check script check for exported symbols (Wladimir J. van der Laan)
92e3022 gitian: don't export any symbols from executable (Wladimir J. van der Laan)
3ab1664 gitian: build against Qt 4.6 (Wladimir J. van der Laan)
The year is 2014. All supported operating systems have IPv6 support,
most certainly at build time (this doesn't mean that IPv6 is configured,
of course).
If noone is exercising the functionality to disable it, that means it
doesn't get tested, and IMO it's better to get rid of it.
(it's also not used consistently in RPC/boost and Net code...)
Last update (48be9ce) missed quite a lot, for some reason.
This is also the first update done with the new script
`contrib/devtools/update-translations.py`
Run this script from the root of the repository to update all translations from transifex.
It will do the following automatically:
- create a transifex configuration file
- fetch all translations
- post-process them into valid and committable format
This is a project-wide configuration file and should be the same for
everyone.
Also remove mention of creating it yourself from the translation process.
- People were having problems with the .so when installing in
alternative locations.
Like gitian, build a static library with -fPIC that can
be embedded into the executables.
- Add some missing steps
- Add reminder that BerkeleyDB is only needed when wallet support is
enabled
Prints the actual version of BerkeleyDB that is linked against, if
wallet support is enabled.
Useful for troubleshooting.
For example:
2014-05-01 07:44:02 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2014-05-01 07:54:25 Using BerkeleyDB version Berkeley DB 5.1.29: (October 25, 20 11)
This avoids conflicts between the libraries statically linked into bitcoin and any
libraries we may link dynamically (such as Qt and OpenSSL, see issue #4094).
It also avoids start-up overhead to not export any unnecessary symbols.
To do this, build a linker script that marks all symbols as local.
Should make it possible to run the resulting GUI executable on
Linux distributions that use Qt 4.6, such as Debian Wheezy and Tails.
Builds a mini-SDK for building against Qt 4.6. This includes the headers
as well as host utilities such as `lrelease`, `qrc` and `moc`.
This speeds up the gitian build a bit - libqt4-dev pulled in a lot of packages,
and is no longer needed as this provides a replacement of our own.
Note: This does not replace the Qt build with at static library. After this
commit we still build dynamically against the system Qt library. The only
difference is that compatibility with an older version is maintained. This
loses minor GUI functionality (such as setPlaceholderText) but still
allows integration into the window management of the host OS, unlike
when statically linking.
Add a script to check that the (Linux) executables produced by gitian
only contain allowed gcc, glibc and libstdc++ version symbols. This
makes sure they are still compatible with the minimum supported Linux
distribution versions.
b39a07d Add missing AssertLockHeld in ConnectBlock (Wladimir J. van der Laan)
41106a5 qt: get required locks upfront in polling functions (Wladimir J. van der Laan)
ed67100 Add required locks in tests (Wladimir J. van der Laan)
0f63504 Changed bitrpc.py's raw_input to getpass for passwords to conceal characters during command line input. Getpass is in Python stdlib so no additional dependencies required. (Eric S. Bullington)
55a1db4 Solve chainActive-related locking issues (Wladimir J. van der Laan)
e07c943 Add AssertLockHeld for cs_main to ChainActive-using functions (Wladimir J. van der Laan)
Because this class replaces some usages of CBigNum, tests have been added to
verify that they function the same way. The only difference in their usage is
the handling of out-of-range numbers.
While operands are constrained to [-0x7FFFFFFF,0x7FFFFFFF], the results may
overflow. The overflowing result is technically unbounded, but in practice
it can be no bigger than the result of an operation on two operands. This
implementation limits them to the size of an int64.
CBigNum was unaware of this constraint, so it allowed for unbounded results,
which were then checked before use. CScriptNum asserts if an arithmetic
operation will overflow an int64_t, since scripts are not able to reach those
numbers anyway. Additionally, CScriptNum will throw an exception when
constructed from a vector containing more than 4 bytes This mimics the previous
CastToBigNum behavior.
