libtool
[Top][All Lists]
Advanced

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

Re: [Rpm-maint] How to get libb to export liba's symbols?


From: Neal H. Walfield
Subject: Re: [Rpm-maint] How to get libb to export liba's symbols?
Date: Tue, 10 May 2022 14:06:51 +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)

On Tue, 10 May 2022 12:48:23 +0200,
Florian Weimer wrote:
> * Neal H. Walfield:
> > On Tue, 10 May 2022 12:04:52 +0200,
> > Florian Weimer wrote:
> >> * Neal H. Walfield:
> >> 
> >> > 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.
> >> 
> >> How is this plug-in mechanism supposed to work?  Via RPM configuration
> >> files?
> >
> > It is a build-time configuration option.  When you configure rpm, you
> > can do:
> >
> >   ./configure --with-crypto=sequoia
> >
> > to get the Sequoia backend.  --with-crypto defaults to libgcrypt,
> > which uses the internal OpenPGP implementation with libgcrypt.  (There
> > is also --with-crypto=openssl, which uses the internal OpenPGP
> > implementation with OpenSSL.)
> 
> That's a very limited form of pluggability.

True.

> I expect the most portable approach (for ELF targets) is to use a stub
> shared object that contains all symbols, including those provided by
> dependencies.  (librpmio.so should probably be a linker script
> referencing the actual object, to prevent accidental loading of
> librpmio.so via dlopen.)  That approach keeps the run-time DT_NEEDED
> value an implementation detail.
> 
> I don't know if libtool supports that out of the box.
> 
> On non-ELF targets, you may need forwarder functions, and the plug-in
> library cannot use the same symbols.

Thanks for the ideas.  Panu also suggested forwarder functions.  That
indeed sounds like the least troublesome from a portability and
robustness perspective.

Thanks,

:) Neal



reply via email to

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