[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to get libb to export liba's symbols?

From: Neal H. Walfield
Subject: How to get libb to export liba's symbols?
Date: Tue, 10 May 2022 11:13:38 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Goj┼Ź) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Hi libtool devs,

Historically, rpm has included its own OpenPGP implementation.  This
implementation is incomplete and buggy, and the maintainers of rpm
have decided that they would like to use a different OpenPGP

There are two major constraints.  Because rpm's OpenPGP API is public,
it must be preserved until the next soname bump.  And, the OpenPGP
backend should be pluggable.

I've recently created an alternate OpenPGP backend for rpm based on
Sequoia PGP.  Sequoia is written in Rust.  I created a Rust shim
(rpm-sequoia), which implements rpm's OpenPGP API:

In other words, I've created a library called librpm_sequoia, which
provides symbols like pgpPubkeyKeyID, which were previously provided
by directly.  That is, using the internal OpenPGP
implementation, includes these symbols:

  $ objdump -T /usr/lib/x86_64-linux-gnu/  | grep pgp | head 
  0000000000018330 g    DF .text        0000000000000101  Base        
  0000000000019200 g    DF .text        000000000000005c  Base        

When using my replacement backend, must continue to
provide these symbols.  In this way, some program foo that links
against librpmio (i.e., has a DT_NEEDED for librpmio) should be able
to use our Sequoia-based librpmio without relinking.  Similarly, a
program foo that is linked against the Sequoia variant of librpmio
should still be usable with a variant of librpmio that uses the
internal OpenPGP implementation.

Unfortunately, I can't figure out how to get librpmio to reexport
librpm_sequoia's symbols.  Currently, foo needs to be relinked
explicitly against  For instance, here you can see
that rpmpgpcheck is now explicitly linked against *and*

  rpmpgpcheck_LDADD = ../rpmio/ \

Before it was enough to just link against

Yes, librpmio is linked against librpm_sequoia:

  librpmio_la_LIBADD = \
        ... \

And the resulting librpmio does have a DT_NEEDED on librpm_sequoia:

  $ objdump -p .libs/ | grep sequoia

And the symbols are mentioned:

  $ objdump -T .libs/ | grep pgp | head -n2
  0000000000000000      DF *UND*        0000000000000000  Base        
  0000000000000000      DF *UND*        0000000000000000  Base        

This appears to be sufficient to resolve librpmio's use of
librpm_sequoia's symbols.  But, when linking a program like
rpmpgpcheck against, the linker does not consider's symbols unless it is explicitly linked against
against  That is, changing rpmpgpcheck to only link
against librpmio:

  rpmpgpcheck_LDADD = ../rpmio/

results in the following errors:

  libtool: link: cc -shared  -fPIC -DPIC  .libs/argv.o .libs/more....o  
-Wl,--whole-archive ../misc/.libs/libmisc.a -Wl,--no-whole-archive  
-L/tmp/rpm-sequoia/release -lrpm_sequoia -lbz2 -lz -lpopt -llzma -llua5.4 -ldl 
-lpthread  -g -O2   -Wl,-soname -Wl, -o .libs/
  libtool: link: cc -Wall -Wpointer-arith -Wmissing-prototypes 
-Wstrict-prototypes -fno-strict-aliasing -fno-strict-overflow 
-fno-delete-null-pointer-checks -Wempty-body -g -O2 -o .libs/rpmpgpcheck 
rpmpgpcheck.o  ../rpmio/.libs/ -ldl -lpthread -Wl,-rpath 
  /usr/bin/ld: rpmpgpcheck.o: undefined reference to symbol 'pgpDigParamsFree'
  /usr/bin/ld: /tmp/rpm-sequoia/release/ error adding 
symbols: DSO missing from command line

My understanding is that this error message means: the symbol
pgpDigParamsFree is needed, it was not found in any of the mentioned
libraries, but it is present in, so link to that.

My conclusion is that I somehow need to get librpmio to reexport
librpm_sequoia's symbols.  Despite spending hours searching, I haven't
figured out how to do that.  I'd appreciate any hints that might lead
me to a solution.


:) Neal

reply via email to

[Prev in Thread] Current Thread [Next in Thread]