* Simon Chopin <chopin.simon@gmail.com>, 2012-01-03, 16:38:
+libchromaprint.so.0 libchromaprint0 #MINVER#[c++ symbols]It's slightly worrisome that these symbols are exported in the first place. OTOH I don't know if there's a simple and upstreamable way to hide them. (Upstream is using cmake.)Yep, I've looked around to find a solution to strip all the template cruft, but so far the only solution I've found would be to do a `strip -x libchromaprint.so.0.1.4`.
Hmm, are you sure "strip -x" helps?
I added a specific symbol file for i386, but I fear the problem will also occur with other architectures.But anyway, on i386 I get this lintian error: E: libchromaprint0: symbols-file-contains-current-version-with-debian-revision on symbol _ZNSt6vectorIdSaIdEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPdS1_EEjRKd@Base and 2 others
Of course it will. :)
Correct me if I'm wrong, but since the previous versions didn't have a symbols file, the shlib system cannot pick a older version, right?+ chromaprint_dealloc@Base 0.6 + chromaprint_decode_fingerprint@Base 0.6 + chromaprint_encode_fingerprint@Base 0.6 + chromaprint_feed@Base 0.6 + chromaprint_finish@Base 0.6 + chromaprint_free@Base 0.6 + chromaprint_get_fingerprint@Base 0.6 + chromaprint_get_raw_fingerprint@Base 0.6 + chromaprint_get_version@Base 0.6 + chromaprint_new@Base 0.6 + chromaprint_start@Base 0.6Why 0.6? As far as I can tell, there were no interface changes in this release, to this should be 0.5 or even lower.
For the shlib system, it's completely irrelevant if the older version had symbol files.
-- Jakub Wilk