search

lipnitsk / libcue

CUE Sheet Parser Library
Other
59 stars 16 forks source link

symbol conflicts with libcdio #8

Open chrysn opened 8 years ago

chrysn commented 8 years ago

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 8 years ago

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 8 years ago

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 libcuecdtext* 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.