[Feature request]: use system libraries for components, if available

[lgbaldoni]

I packaged freac (and consequently BoCA) for openSUSE Tumbleweed and I noticed there are several in-tree third party libraries and that might constitute a problem for the package to be accepted.

So, my questions are:

1. Are faac/flac/vorbis/... sources patched?
2. If not, do you use private symbols?

[enzo1982]

Thank you for packaging fre:ac for openSUSE! It would be great to see fre:ac become available in more distribution repositories!

The only in-tree libraries that are built by default are libid3v2 and libxspf. libid3v2 is heavily modified with support for chapters and bug fixes, so the regular libid3v2 cannot be used. Also, the upstream project has been abandoned a long time ago.

libxspf is built, because it's not available in most distribution repositories. If it is available in openSUSE, you can build BoCA with make config=systemlibxspf to use the system library.

When it comes to codecs, the BoCA tree only includes their header files, not the actual source code. Most of the codec components load the respective libraries dynamically at run time (with dlopen), so including the headers ensures that the components can be built without the actual codecs installed.

The binary packages provided for fre:ac (AppImages) come with their own binary codec libraries. Some of these are patched to include performance optimizations or minor fixes, but you should be able to use the packaged versions of these libraries for openSUSE. No need to build special versions of the codecs.

A full list of the codec libraries used in fre:ac AppImages can be found here: https://www.freac.org/downloads-mainmenu-33/214-codec-sources-and-patches

Similarly to BoCA with libxspf, the smooth library builds its own copy of libcpuid. As with libxspf, this can be turned off by building with make config=systemlibcpuid.

[lgbaldoni]

When it comes to codecs, the BoCA tree only includes their header files, not the actual source code. Most of the codec components load the respective libraries dynamically at run time (with dlopen), so including the headers ensures that the components can be built without the actual codecs installed.

So it's lazy linking?

I understand this is not a problem when all binaries are supplied; what concerns me here is that there could be a version mismatch between said headers and the library packaged on each distro that would emerge only at runtime.

Will try and patch makefiles and see what happens.

[enzo1982]

So it's lazy linking?

Yes, it is.

In practice, API incompatibilities do not seem to be a real issue when it comes to codec libraries. It virtually never happens that new codec versions introduce incompatible changes like changing public structs or changing function arguments without changing the function name.

But anyway, patching the Makefiles to not add the source path to the include search paths should lead to the system-wide installed headers being used.