Open robUx4 opened 2 years ago
This is needed when the host app is coded in C and has no idea that chromaprint uses C++ internally.
@robUx4 Could you post the diff of the pkg-config config on all platforms? The change are kind of hard to review and the diffs would help a lot.
As the C++ library is only needed for static linking, this should be added only to Libs.private
if at all.
Indeed and static linking is tricky for multiple reasons, it's much better to just include the libraries needed for the particular build in the project's build system.
On a Linux build, Before:
Name: chromaprint
Description: Audio fingerprint library
URL: http://acoustid.org/chromaprint
Version: 1.4.2
Libs: -L/root/build/contrib/x86_64-linux-gnu/lib -lchromaprint
Cflags: -I/root/build/contrib/x86_64-linux-gnu/include
After:
Name: chromaprint
Description: Audio fingerprint library
URL: http://acoustid.org/chromaprint
Version: 1.4.2
Libs: -L/root/build/contrib/x86_64-linux-gnu/lib -lchromaprint -L/root/build/contrib/x86_64-linux-gnu/lib -lavcodec -pthread -lm -latomic -lz -lgsm -lmp3lame -lm -lopenjp2 -lm -lavutil -pthread -lm -latomic -lstdc++ -lm -lc
Cflags: -I/root/build/contrib/x86_64-linux-gnu/include
I agree it my be better in Libs.private
. Things like -pthread
also don't belong here. Other dependencies like zlib might be handled through Requires:
but that's a bit more work.
The C++ runtime to use is needed because the library can be used with a C interface. The host app cannot guess what it really needs to link to. When used from C++ code it will pick its own runtime (and should match the one from the library).
When linking statically with chromaprint the app needs to know which libraries to link with. It also needs the C++ runtime if the calling code doesn't have any C++.