[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFR: chromaprint (Adoption)

* 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?

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
I added a specific symbol file for i386, but I fear the problem will also occur with other architectures.

Of course it will. :)

+ 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.6

Why 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.
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?

For the shlib system, it's completely irrelevant if the older version had symbol files.

Jakub Wilk

Reply to: