multilib EXTRA_LIB not included in pkg-config file

[Former user]

When building multilib-static, the lib added via EXTRA_LIB is not added to the Libs section of x265.pc, which causes FFmpeg to fail the configure check due to not knowing about the additional x265 lib. In my case, the EXTRA_LIB was libx265_main10.a, installed to the system by itself, followed by an 8bit libx265 and co., also installed to the system.

However, if I simply append -lx265_main10 to the end of the Libs section (sed -i 's/lx265/lx265 -lx265_main10/' x265.pc), then FFmpeg is fine again, everything completes successfully, and I have access to both 8bit and 10bit encoding as designed.

The user shouldn't have to be tasked with knowing that they have to manually add that lib to their pkg-config file, though. Especially since it could also require permission wrangling if they do it after the make install step rather than after running make but before running make install.

[Steve Borho]

It's not clear we'll ever support install rules (including pkg-config) for static multilib, because these libraries will not be useful for applications which use the full exported C API. The only two applications which can link to static multilib, that I am aware of, are ffmpeg and our CLI

[Steve Borho]

cmake: export C API from multilib, enables multibit shared libs (fixes #153)

With these changes, one can add additional bit depths to any shared lib by compiling the other bit depths with EXPORT_C_API=OFF and then linking those libraries into the "default" build using EXTRA_LIB and then the appropriate LINKED_??BIT cmake options. The default build does export the C API and thus is a fully functional library even for applications which do not yet use the introspection methods.

The batch files show an example of how to make an 8bit lib which includes 10 and 12bit libraries.

Note this also closes #154 since users should be building a single combined shared lib which needs no additional link libraries specified in x265.pc

→ <<cset 0905ecb7d8b8>>