fontconfig: keep track of, and free, our configuration
Inspite of claims to the contrary in fontconfig 2.11 changes log, FontConfig is really not thread-safe, since it uses atomic pointers instead of proper reference counting. Consequently, LibVLC cannot safely call FcFini() - it could crash another thread using FontConfig concurrently. Using our own configuration has the benefit of not leaking related memory allocations, though it means that the LibVLC text renderer cannot share the configuration with other components in the same process. Note that there are still leaks within FontConfig. Specifically, the cache and the language/program default values are not freed, since that would require FcFini(). If you care in your application, call FcFini() after you have terminated all LibVLC instances. Refs #16023.
Showing with 56 additions and 19 deletions