neobytes/depends
Cory Fields 0246ab6088 depends: boost: hard-code hidden symbol visibility
tl;dr: This solves boost visibility problems for default/release build configs
on non-Linux platforms.

When Bitcoin builds against boost's header-only classes, it ends up with
objects containing symbols that the upstream boost libs also have. Since
Bitcoin builds by default with hidden symbol visibility, it can end up trying
to link against a copy of the same symbols with default visibility.
This is not a problem on Linux because 3rd party static libs are un-exported
by default (--exclude-libs,ALL), but that is not available for MinGW and OSX.

Those platforms (and maybe others?) end up confused about which version to use.

The OSX linker spews hundreds of: "ld: warning: direct access in <foo> to
global weak symbol guard variable for <bar> means the weak symbol cannot be
overridden at runtime. This was likely caused by different translation units
being compiled with different visibility settings."

MinGW's linker complains similarly.

Since the default symbol visibility for Bitcoin is hidden and releases are
built that way as well, build Boost with hidden visibility. Linux builds Boost
this way also, but only for the sake of continuity.

This means that the linker confusion logic is reversed, so the problem will
will now be encountered if Bitcoin is built with --disable-reduce-exports, but
that's better than the current situation.
2014-11-05 01:16:53 -05:00
..
builders depends: add sensible download timeout/retry values 2014-08-27 03:40:30 -04:00
hosts depends: add debug/release flags for linux/osx/win 2014-09-25 14:56:26 -04:00
packages depends: boost: hard-code hidden symbol visibility 2014-11-05 01:16:53 -05:00
patches qt: fix tablet crash. closes #4854. 2014-09-08 14:42:46 -04:00
.gitignore depends: add shared dependency builder 2014-08-08 15:10:46 -04:00
config.guess depends: add shared dependency builder 2014-08-08 15:10:46 -04:00
config.site.in Bugfix: Replace bashisms with standard sh in gitian descriptors 2014-10-03 23:45:26 +00:00
config.sub depends: add shared dependency builder 2014-08-08 15:10:46 -04:00
funcs.mk depends: add the debug/release concept to depends 2014-09-25 14:56:25 -04:00
Makefile depends: add the debug/release concept to depends 2014-09-25 14:56:25 -04:00
README depends: add shared dependency builder 2014-08-08 15:10:46 -04:00
README.packages depends: add docs for debug 2014-09-25 14:56:26 -04:00
README.usage depends: add docs for debug 2014-09-25 14:56:26 -04:00

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.