On 04/14/2014 02:43 AM, Dmitry Smirnov wrote:
On Mon, 14 Apr 2014 12:09:59 Michael Tokarev wrote:
14.04.2014 11:42, Dmitry Smirnov wrote:
I found it so difficult to maintain symbols in C++ libraries so I just
used
"dh_makeshlibs -V" and it never failed me.
Yeah, it never fails, but it has its own downside which I mentioned
above.
Thank you for all your comments. I'm with you, I understand how useful
.symbols could be for linking (if done properly).
Specifically in regards to Ceph for a moment I feel much more comfortable with
"dh_makeshlibs -V" not only due to lack of confidence in C++ symbols approach
but mostly because of rapid upstream development. The amount of changes
between 0.72.2 and 0.79 is huge. I would feel quite uncomfortable if "qemu"
would be built successfully with 0.79 but wouldn't pull newer libraries when
used with 0.72.2... For example Ceph cluster has to be completely upgraded to
0.79 as it just doesn't work with mix of 0.72.2 and 0.79 components (i.e.
OSD,MON,MDS)...
As a ceph developer, the mixed-cluster issue is a bug (possibly fixed
already since 0.79 is undergoing heavy testing and fixes before the
next long term stable release, 0.80, is out). If you have more details
we'd be happy to hear about them.
Regarding library symbols, the ceph libraries each have C++ as well as
C interfaces, and there's been some suggestions to move to
visibility=hidden by default, to avoid some of the hairier problems
with C++ libraries [1]. It seems like this would make .symbols files
approach more tenable, since passing through all C++ symbols would
not be as bad if only the desired ones are exported in the first place.
This isn't done yet, but in the mean time the "dh_makeshlibs -V"
approach seems fine to me.
If there's anything we could do upstream to make this easier, let us know.
Thanks!
Josh
[1] http://marc.info/?l=ceph-devel&m=138842618710279
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
