diff options
author | Carl Dong <accounts@carldong.me> | 2019-05-15 13:50:01 -0400 |
---|---|---|
committer | Carl Dong <accounts@carldong.me> | 2019-05-28 10:51:18 -0400 |
commit | 14209286df4a91a0e6738268339ba667d868a11f (patch) | |
tree | d1d2a7fc52d8c4a99b4032b009c78f71b75eb253 /depends/packages.md | |
parent | 76e2cded477bc483ec610212bdadf21fe35292d4 (diff) |
depends: Build secondary deps statically.
Secondary dependencies don't need to be shared.
Diffstat (limited to 'depends/packages.md')
-rw-r--r-- | depends/packages.md | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/depends/packages.md b/depends/packages.md index 7d2bd4670d..ccdc858593 100644 --- a/depends/packages.md +++ b/depends/packages.md @@ -5,6 +5,10 @@ The package "mylib" will be used here as an example General tips: - mylib_foo is written as $(package)_foo in order to make recipes more similar. +- Secondary dependency packages relative to the bitcoin binaries/libraries (i.e. + those not in `ALLOWED_LIBRARIES` in `contrib/devtools/symbol-check.py`) don't + need to be shared and should be built statically whenever possible. See + [below](#secondary-dependencies) for more details. ## Identifiers Each package is required to define at least these variables: @@ -146,3 +150,22 @@ $($(package)_config_opts) will be appended. Most autotools projects can be properly staged using: $(MAKE) DESTDIR=$($(package)_staging_dir) install + +## Secondary dependencies: + +Secondary dependency packages relative to the bitcoin binaries/libraries (i.e. +those not in `ALLOWED_LIBRARIES` in `contrib/devtools/symbol-check.py`) don't +need to be shared and should be built statically whenever possible. This +improves general build reliability as illustrated by the following example: + +When linking an executable against a shared library `libprimary` that has its +own shared dependency `libsecondary`, we may need to specify the path to +`libsecondary` on the link command using the `-rpath/-rpath-link` options, it is +not sufficient to just say `libprimary`. + +For us, it's much easier to just link a static `libsecondary` into a shared +`libprimary`. Especially because in our case, we are linking against a dummy +`libprimary` anyway that we'll throw away. We don't care if the end-user has a +static or dynamic `libseconday`, that's not our concern. With a static +`libseconday`, when we need to link `libprimary` into our executable, there's no +dependency chain to worry about as `libprimary` has all the symbols. |