On Fri, Aug 12, 2011 at 01:28:59PM -0400, Adam Jackson wrote: > On 8/12/11 12:28 PM, Matthew Garrett wrote: > > On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: > > > >> Third party code built against -devel and depending only on the SONAME is fine > >> in this situation as it sticks to the published ABI. In-tree code that plays > >> with non-ABI symbols will break and so may need a stricter dep. > > > > It is in this situation, but there are other situations where depending > > on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, > > anything built against it may fail to run against libfoo 1.0. But how > > will you know that in advance if all you have in your dependencies is > > the SONAME? > > In fairness, this is why rpm elaborates soname dependencies to also > include symbol versions. It's a pity that symbol versions are so > painful to use that really only glibc makes any effort to do it. We make use of them in libvirt, via the '-Wl,--version-script=libvirt.syms'. While it is slightly unfortunate to have to specify versions outside the header file definitions, it isn't a significant problem. It is immediately obvious if you forget to add new public APIs to sym file, since you won't be able to link/test against them. So I wouldn't really call symbol versoning painful. What is unfortunate, is that if your library wants to also be maintained on non-Linux platforms, then you can't make full use of the things that glibc's versioning lets you do. eg introducing new APIs with the same name, but different ABI, while not breaking existing linked apps. 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 :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
