dbus-daemon statically linked with libdbus-1?

[Daniel P. Berrange]

On Wed, Jun 04, 2014 at 12:48:45PM -0700, Colin Walters wrote:
> On Wed, Jun 4, 2014, at 12:29 PM, Daniel P. Berrange wrote:
> > 
> > 3) Use symbol versioning and export the private functions with
> >    a versioned symbol postfix. eg dbus_foo at DBUS_PRIVATE_X.Y.Z.
> >    Makes it pretty clear to apps developers that they shouldn't
> >    use that symbol, and ensures that you must have a matching
> >    version of dbus-daemon + libdbus.so. To make it extra clever
> >    you could make use of a random hash generated at build time
> >    instead of version number, so you can only ever use exact
> >    matched dbus-daemon + libdbus.so from the same build
> 
> Yeah, I could imagine that one working well.  Presumably you have
> some sample automake/linker scripts out there for this?  If so,
> can you link?

In libvirt.so we have a simple make rule which takes libvirt_private.syms
file and puts it in a LIBVIRT_PRIVATE_$VERSION block, and combines that
with our main libvirt_public.syms file

  http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/Makefile.am;h=d82ca265a644f7bd2a22e9d2f2403b090414a7c7;hb=HEAD#l1913

eg

  $ eu-readelf -a /usr/lib64/libvirt.so | grep @@LIBVIRT_PRIVATE
  609: 0000000000071540    236 FUNC    GLOBAL DEFAULT       12 virCgroupNewVcpu@@LIBVIRT_PRIVATE_1.2.5
  610: 00000000000ac2e0    619 FUNC    GLOBAL DEFAULT       12 virPCIDeviceFileIterate@@LIBVIRT_PRIVATE_1.2.5
  611: 00000000000e34f0     14 FUNC    GLOBAL DEFAULT       12 virDomainObjGetState@@LIBVIRT_PRIVATE_1.2.5
  612: 00000000000c5bb0    306 FUNC    GLOBAL DEFAULT       12 virXPathLongLong@@LIBVIRT_PRIVATE_1.2.5
  614: 00000000000b2660    100 FUNC    GLOBAL DEFAULT       12 sexpr_node_copy@@LIBVIRT_PRIVATE_1.2.5
  ....snip...

GLibC also uses this approach except they just append 'GLIBC_PRIVATE'
with no version number.

  $ eu-readelf -a /usr/lib64/libc.so.6  | grep @@GLIBC_PRIVATE | head
   26: 00000000000eba80     33 FUNC    GLOBAL DEFAULT       12 __getrlimit@@GLIBC_PRIVATE
   27: 000000000010e370    119 FUNC    GLOBAL DEFAULT       12 __internal_endnetgrent@@GLIBC_PRIVATE
   42: 00000000000bc9c0    683 FUNC    GLOBAL DEFAULT       12 __libc_fork@@GLIBC_PRIVATE
  165: 0000000000102bc0     90 FUNC    GLOBAL DEFAULT       12 __libc_pthread_init@@GLIBC_PRIVATE
  212: 0000000000117950    296 FUNC    GLOBAL DEFAULT       12 __nss_next2@@GLIBC_PRIVATE

> One minor downside of this is I can imagine some ABI checking
> tools (e.g. http://upstream-tracker.org/ ) completely losing
> their marbles with it unless they were taught to search for
> the _PRIVATE_ string or so.

Seems upstream-tracker.org has some logic for this, since AFAICT it
isn't complaining about libvirt's LIBVIRT_PRIVATE_X.Y.Z symbol changing
on every release.  Whether they've special cased libvirt or just whitelist
any symboil with PRIVATE in the version, I can't tell.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|