Secondary dependencies don’t need to be shared. Comes at theuni’s request.
To do: add documentation so future secondary dependencies aren’t shared. DONE
Let’s merge this first as #15844 is based on this PR.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
4@@ -5,6 +5,9 @@ The package "mylib" will be used here as an example
5
6 General tips:
7 - 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.
It improves general build reliability.
For 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, libprimary
has all the symbols.
Perhaps @theuni can add more.
depends/packages.md
.
163+not sufficient to just say `libprimary`.
164+
165+For us, it's much easier to just link a static `libsecondary` into a shared
166+`libprimary`. Especially because in our case, we are linking against a dummy
167+`libprimary` anyway that we'll throw away. We don't care if the end-user has a
168+static or dynamic `libseconday`, that's not our concern. With a static
Secondary dependencies don't need to be shared.
Concept ACK, thanks for picking this up!
Reviewing.
diffoscope x86_64-pc-linux-gnu/lib x86_64-pc-linux-gnu-3560d8c/lib
0libX11-xcb.so.1.0.0
1libX11.la
2libX11.so
3libX11.so.6
4libX11.so.6.3.0
5libXau.a
6libXau.la
7+libXext.a
8libXext.la
9-libXext.so
10-libXext.so.6
11-libXext.so.6.4.0
12libboost_chrono-mt.a
13libboost_filesystem-mt.a
14libboost_prg_exec_monitor-mt.a
15libboost_system-mt.a
16libboost_test_exec_monitor-mt.a
17libboost_thread-mt.a
18libboost_timer-mt.a
19libboost_unit_test_framework-mt.a
20libcrypto.a
21libdb-4.8.a
22libdb.a
23libdb_cxx-4.8.a
24libdb_cxx.a
25+libdbus-1.a
26libdbus-1.la
27-libdbus-1.so
28-libdbus-1.so.3
29-libdbus-1.so.3.14.11
30libevent.a
31libevent.la
32libevent_core.a
33libevent_core.la
34libevent_extra.a
35libevent_extra.la
36libevent_pthreads.a
37libevent_pthreads.la
38+libexpat.a
39libexpat.la
40-libexpat.so
41-libexpat.so.1
42-libexpat.so.1.6.8
43libfontconfig.la
44libfontconfig.so
45libfontconfig.so.1
46libfontconfig.so.1.9.2
47libfreetype.la
48libfreetype.so
49libfreetype.so.6
A few things about this make me nervous, so I’m going to look in more depth.
In this PR we identify 4 secondary deps that should be built statically:
However, only expat required being built --with-pic
for depends builds to succeed, which is rather odd. Therefore, the rest of the deps must not be linked in, or are headers-only.
Results of my investigation (please verify these as I might be completely wrong):
The only package that we declare as depending on libXext is qt, and it doesn’t actually… Tested by removing the package definition and references to it, everything seems to compile fine.
It seems that xtrans is just code+headers and not a library that needs to be linked in. We can verify this by looking at the build outputs.
Its configure is very confused as to why we supply it with --disable-{static,shared}
. It is, however, required as a build-time dependency for libX11.
The only reference to dbus is in the configure options for qt: -dbus-runtime
. Which indicates to qt to dynamically open libdbus-1 at runtime (with dlopen?). I believe this means that we don’t actually use the dbus we build. (This one I’m the least sure about)
@theuni