Problems after Update on taglib-1.10-1

[Tsuda Kageyu]

Hi Urs,

The parameter UTF16BE and UTF16LE are somewhat confusing. Unlike their
name, UTF16BE means "the system byte order" and UTF16LE means "contrary to
the system byte order" in TagLib 1.8 and 1.10. I introduced WCharByteOrder
in v1.9 to straighten it out, but it caused some binary incomatibility
between v1.8 and v1.9, so we reverted it in v1.10.

Privately, I think that either way (keep the compatibility with v1.8 or
v1.9) is logical accordingly. v1.9 is not compatible with older versions,
but has been used for a long time...

Regards,
Kageyu

2015-12-09 6:07 GMT+09:00 Urs Fleisch <urs.fleisch at gmail.com>:

> 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 UTF16 strings.
>
> It seems that applications linked against TagLib 1.9 have to be recompiled.
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20151209/eed47fe2/attachment.html>