14.04.2014 10:47, Dmitry Smirnov wrote: > Hi Michael, Hello!
> On Sun, 13 Apr 2014 18:32:05 Michael Tokarev wrote: [] >> That to say, linking programs with librbd or librados breaks those >> programs in random way. > > Thank you for detailed report. This is the same as #680307, I think the two should be just merged together. [] > By the way do you think that just using "dh_makeshlibs -V" would be > sufficient? Although I committed .symbols files I've never had good > experience > with symbols in C++ libraries and I have concerns for potential build > problems > on multiple architectures... Yes, this has happened in the past - a naive attempt to use dh_makeshlibs -V resulted in package FTBFS on all arches except of the one where makeshlibs were run, due to differences in complier and architectures wrt C++ symbols. I don't know ceph internals. If those C++ symbols are internal, and only regular symbols should be exposed, maybe just hiding them all should be a good idea. If, on the other hand, those are parts of public ABI, I'm afraid there's no good solution except of the way you did it -- making all C++ symbols to be part of the latest release. Note that makeshlibs supports symbols.arch file in addition to symbols file, maybe that one can be used to export (limited) set of C++ ABI. I too have no expirience with C++ exporting and .symbols files. Besides, you added the two .symbols files into 0.79 package, -- maybe you may run makeshlibs on 0.72 instead (or even on 0.44/0.48), to generate initial .symbols files, and run mkshlibs again on new version(s) to make additions. This way, even older lib may be used for symbols which were present long time ago. Dunno how important it is. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
