mirror of
https://github.com/bitcoin/bitcoin.git
synced 2024-11-20 02:25:40 +01:00
4fe6c3c24f
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. |
||
|---|---|---|
| .. | ||
| builders | ||
| hosts | ||
| packages | ||
| patches | ||
| .gitignore | ||
| config.guess | ||
| config.site.in | ||
| config.sub | ||
| funcs.mk | ||
| Makefile | ||
| README | ||
| README.packages | ||
| README.usage | ||
This is a system of building and caching dependencies necessary for building Bitcoin. There are several features that make it different from most similar systems: - It is designed to be builder and host agnostic In theory, binaries for any target OS/architecture can be created, from a builder running any OS/architecture. In practice, build-side tools must be specified when the defaults don't fit, and packages must be ammended to work on new hosts. For now, a build architecture of x86_64 is assumed, either on Linux or OSX. - No reliance on timestamps File presence is used to determine what needs to be built. This makes the results distributable and easily digestable by automated builders. - Each build only has its specified dependencies available at build-time. For each build, the sysroot is wiped and the (recursive) dependencies are installed. This makes each build deterministic, since there will never be any unknown files available to cause side-effects. - Each package is cached and only rebuilt as needed. Before building, a unique build-id is generated for each package. This id consists of a hash of all files used to build the package (Makefiles, packages, etc), and as well as a hash of the same data for each recursive dependency. If any portion of a package's build recipe changes, it will be rebuilt as well as any other package that depends on it. If any of the main makefiles (Makefile, funcs.mk, etc) are changed, all packages will be rebuilt. After building, the results are cached into a tarball that can be re-used and distributed. - Package build results are (relatively) deterministic. Each package is configured and patched so that it will yield the same build-results with each consequent build, within a reasonable set of constraints. Some things like timestamp insertion are unavoidable, and are beyond the scope of this system. Additionally, the toolchain itself must be capable of deterministic results. When revisions are properly bumped, a cached build should represent an exact single payload. - Sources are fetched and verified automatically Each package must define its source location and checksum. The build will fail if the fetched source does not match. Sources may be pre-seeded and/or cached as desired. - Self-cleaning Build and staging dirs are wiped after use, and any previous version of a cached result is removed following a successful build. Automated builders should be able to build each revision and store the results with no further intervention.