Problems after Update on taglib-1.10-1
urs.fleisch at gmail.com
Tue Dec 8 21:07:08 UTC 2015
I can confirm these problems on Arch Linux. I have tested it with kid3. If
I use kid3 3.3.0-3, which was built against TagLib 1.9.1, and currently
dynamically links to TagLib 1.10 on Arch Linux, I have the same situation:
Saved tags are stored with wrong characters. If I build kid3 against TagLib
1.10, the problems disappear. As Walter Schineis reported, the problems are
solved when downgrading to TagLib 1.9.1. This looks like a binary
incompatibility between the two versions.
I have used abi-compliance-checker and found the following:
In TagLib 1.9.1, we had the following
String(const wstring &s, Type t = WCharByteOrder);
String(const wchar_t *s, Type t = WCharByteOrder);
where WCharByteOrder is a private static const String::Type, which will be
initialized to UTF16LE on little endian systems (as most of our PCs are).
In TagLib 1.10 we have
String(const wstring &s, Type t = UTF16BE);
String(const wchar_t *s, Type t = UTF16BE);
with a default of UTF16BE. The default encoding seems to have changed from
UTF16LE to UTF16BE. If a program is built against TagLib 1.9.1 and uses one
of these String constructors with a default parameter for the type, the
compiler will assign the value of WCharByteOrder (which still exists in
TagLib 1.10 and is still UTF16LE) to the type parameter. The code in the
constructor in TagLib 1.10 now tries to do something for compatibility with
TagLib 1.8 (had same signatures for these constructors as TagLib 1.10), but
this will fail if the application was linked against TagLib 1.9.1.
So it seems that TagLib 1.10 is compatible with TagLib 1.8, but not with
TagLib 1.9. The ChangeLog contains
Fixed backwards-incompatible change in TagLib::String when constructing
It seems that applications linked against TagLib 1.9 have to be recompiled.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the taglib-devel