lipnitsk/libcue

symbol conflicts with libcdio

chrysn opened this issue · 2 comments

chrysn commented

libcue has had a long-standing issue of being incompatible with libcdio, making it unusable for programs that want to link against both. this has led to the removal of libcue-derived features from mpd in debian, where issue is discussed at 597731.

with the reuptaken development of libcue, do you see a chance of changing the symbols in future releases?

lipnitsk commented

It looks like the only exported symbol in libcue 2.0.1 that conflicts with libcdio is cdtext_get. That seems to be a problem. I suppose the conflict could be resolved with an ABI-breaking change in libcue 3.0. Does mpd intend to use libcdio and libcue together?

chrysn commented

On Tue, Mar 08, 2016 at 11:07:21PM -0800, Ilya Lipnitskiy wrote:

It looks like the only exported symbol in libcue 2.0.1 that
conflicts with libcdio is cdtext_get. That seems to be a problem.
I suppose the conflict could be resolved with an ABI-breaking change
in libcue 3.0.

it seems to me that cdtext_init is affected as well, as is cdtext_set.

an abi update should be possible without breaking the api (eg. by
renaming the functions to libcue_cdtext_* and #define-ing the old names
to the new ones), i just don't know if that is really best practice.

there is an analysis of who (at least in debian) uses the symbols in
a comment on the mpd issue.
arch has a live online list of
reverse dependencies,
which covers well what i see on debian with apt-cache rdepends libcue1.

Does mpd intend to use libcdio and libcue together?

yes. currently, mpd in debian links against libcdio13 via libiso9660 and
not against libcue since the abovementioned bug, but that means that the
embcue plugin needs to be disabled at compile time. a libcue that is
compatible with libcdio should allow re-enabling the cuesheet support.