This has historically been the case in autotools since we want vercmp to not break mid-transaction in an install script. For convenience, we create libalpm.a and use this to optionally generate libalpm.so (when not configured with -Dbuildstatic=true) as well as to link any binary which explicitly wishes to be built statically "with libalpm", but does not care where a function is defined. meson then treats this correctly: it builds the object file only once for both libraries, and the compiler strips out unused functionality from the final static binary. Currently the only binary which requires this is vercmp. Fixes FS#61719 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- This is based on my initial suggestion via IRC for how to solve the vercmp build issue using two libalpm libraries. The important distinction is that in order to not be an error when buildstatic is used, we cannot try to create multiple rules that generate libalpm.a -- and also we don't want to install /usr/lib/libalpm_a.a meson.build | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/meson.build b/meson.build index 0a710653..4a74786b 100644 --- a/meson.build +++ b/meson.build @@ -354,15 +354,24 @@ libcommon = static_library( include_directories : includes, install : false) -libalpm = library( +libalpm_a = static_library( 'alpm', libalpm_sources, - version : libalpm_version, include_directories : includes, dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, link_with : [libcommon], install : true) +if not get_option('buildstatic') + libalpm = shared_library( + 'alpm', + version : libalpm_version, + link_whole: [libalpm_a], + install : true) +else + libalpm = libalpm_a +endif + install_headers( 'lib/libalpm/alpm.h', 'lib/libalpm/alpm_list.h') @@ -413,7 +422,7 @@ executable( 'vercmp', vercmp_sources, include_directories : includes, - link_with : [libalpm], + link_with : [libalpm_a], install : true, ) -- 2.20.1