@@ -5,6 +5,10 @@ The package "mylib" will be used here as an example
55
66General tips:
77- mylib_foo is written as $(package)_ foo in order to make recipes more similar.
8+ - Secondary dependency packages relative to the bitcoin binaries/libraries (i.e.
9+ those not in ` ALLOWED_LIBRARIES ` in ` contrib/devtools/symbol-check.py ` ) don't
10+ need to be shared and should be built statically whenever possible. See
11+ [ below] ( #secondary-dependencies ) for more details.
812
913## Identifiers
1014Each package is required to define at least these variables:
@@ -146,3 +150,22 @@ $($(package)_config_opts) will be appended.
146150Most autotools projects can be properly staged using:
147151
148152 $(MAKE) DESTDIR=$($(package)_staging_dir) install
153+
154+ ## Secondary dependencies:
155+
156+ Secondary dependency packages relative to the bitcoin binaries/libraries (i.e.
157+ those not in ` ALLOWED_LIBRARIES ` in ` contrib/devtools/symbol-check.py ` ) don't
158+ need to be shared and should be built statically whenever possible. This
159+ improves general build reliability as illustrated by the following example:
160+
161+ When linking an executable against a shared library ` libprimary ` that has its
162+ own shared dependency ` libsecondary ` , we may need to specify the path to
163+ ` libsecondary ` on the link command using the ` -rpath/-rpath-link ` options, it is
164+ not sufficient to just say ` libprimary ` .
165+
166+ For us, it's much easier to just link a static ` libsecondary ` into a shared
167+ ` libprimary ` . Especially because in our case, we are linking against a dummy
168+ ` libprimary ` anyway that we'll throw away. We don't care if the end-user has a
169+ static or dynamic ` libseconday ` , that's not our concern. With a static
170+ ` libseconday ` , when we need to link ` libprimary ` into our executable, there's no
171+ dependency chain to worry about as ` libprimary ` has all the symbols.
0 commit comments