I want to get it all right this time, finally. My bugreport was wrong and confusing from the start, and I messed up with it several times after that.
So, what I mean was really to have shlibs file with the right versions (which was missing for both librbd and librados), OR symbols files (also for both libraries). Not symvers, as it is about something else -- about having several versions of the same symbol in the library, for backwards compatibility. Now, for C++ symbols, using symbols mechanism (dpkg-gensymbols &Co) appears to be difficult, since different architectures generates different final symbols for the same function. It is possible to work around this problem by using non-mangled symbols (c++filt < debian/librbd1.symbols) and tagging these with "c++" (man dpkg-gensymbols). The next problem is that depending on lots of factors, gcc may sometimes export symbols which are inlinable and used (in non-inlined form) internally by the library too. Such symbols wont be used by other programs linked with the library, -- gcc will either inline them there, or implement a new non-inlined "instance" of it. But these symbols will appear and disappear depending on arcitecture, compiler version, compiler options, etc, and it will constantly give headaches to maintain these properly. There's a gcc option whcih may help with this aspect: it is -fvisibility-inlines-hidden, which makes such inlined functions hidden. There's also another approach, by using the same tools as used by KDE team, described here: http://pkg-kde.alioth.debian.org/symbolfiles.html I'm not sure which approach to take here - plain shlibs, or using symbols file managed one or another way. Either approach will do, as long as it is used properly. Ofcourse symbols variant is preferrable, unless it takes huge efforts to maintain the symbols file. But it is solely the maintainer decision. But it needs to be fixed somehow, current package FTBFS on all architectures but amd64... :( Thank you for your patience! Hopefully this clears things up and helps somewhat. And big thanks to Sune Vuorela and other nice people in #debian @irc.oftc.net, who described it all to me. /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
