14.04.2014 11:42, Dmitry Smirnov wrote:
> On Mon, 14 Apr 2014 11:23:29 Michael Tokarev wrote:
>> 14.04.2014 10:47, Dmitry Smirnov wrote:
>>> 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.
>
> Actually I thought that "dh_makeshlibs -V" would be safe to use, safer than
> adding .symbols file(s) but perhas not that flexible... I'm considering to
> make upload of 0.72.2-3 with "dh_makeshlibs -V" -- would you recommend not to
> do that?
> How "dh_makeshlibs -V" can cause FTBFS?
Um. I misunderstood.
dh_makeshlibs can generate shlibs file and/or use symbols file. Ofcourse,
using dh_makeshlibs -V without .symbols file is safe, but not very useful
as comments in man dh_makeshlibs says:
Beware of using -V without any parameters; this is a conservative
setting that always ensures that other packages' shared library
dependencies are at least as tight as they need to be (unless your
library is prone to changing ABI without updating the upstream
version number), so that if the maintainer screws up then they
won't break. The flip side is that packages might end up with
dependencies that are too tight and so find it harder to be
upgraded.
In other words, it solves the immediate problem, but it might become more
problematic in the future, since we'll have migration probs every time
upstream version changes.
What I mean about FTBFS is that there was a naive attempt to provide .symbols
files, which, together with C++ instability over architectures, resulted in
FTBFS. Ofcourse it was done using dh_makeshlibs. Which has little to do
with your question.
>> 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.
>
> I wish I knew the answer to those questions. :)
Hm. That's.. interesting indeed ;)
Maybe we can ask upsteam for some comments? Maybe they'll even consider
providing version-script files for gcc/linker in the same way many other
libs are providing, to clean up the list of exports they're doing.
Actually this might not be that a bad idea. See eg
http://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html
http://www.akkadia.org/drepper/dsohowto.pdf
(the first link is about aix but still useful). I can't immediately find
a very good (and short) writeup about this and gnu linker, I remember
coming across this somewhere before.
> By the way thank you for
> useful comments in
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679686#53
>
>> 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.
>
> Thank you, I'll remember that.
There's more to this: a single symbols file may contain arch-specific
symbols with quite flexible syntax.
>> I too have no expirience with C++ exporting and .symbols files.
>
> 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.
>> 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.
>
> Will do, that's exactly what I was thinking about. Just need a bit more time
> to build... :)
>
> Thank you.
And thank you too for tryin to clear the mess!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
