Mon, 08/03/2020 - 19:06
Forums:
Currently it seems like the CMake build (and others for that matter) just add `-lfontconfig` to the link line. I've looked through the CMake code and haven't been able to decipher how to make it find fontconfig like it does freetype. Would it be possible for this to be done at least for fontconfig (though other third party libraries should also get the same treatment)?
Mon, 08/03/2020 - 19:28
fontconfig is considered as a system library in case of Linux (its configs are used to determine font files location) - like Xlib and similar, which don't have a dedicated 3rdparty library search routine.
Why would you want using an external fontconfig library?
Mon, 08/03/2020 - 19:31
We're building our package on an older CentOS. Building against an old fontconfig crashes when run on newer Linux distros due to fonts.conf syntax changes. Using a newer fontconfig on the older distro and shipping it just warns about the old syntax used on older distros which is a much better outcome.
Mon, 08/03/2020 - 20:04
I would say that you may build OCCT with an old (system) fontconfig and package it with the new fontconfig library, but I suppose that in your case fontconfig has different versions in SO-name, so that linker will keep looking for an older version of fontconfig?
Could you please also mention the versions of CentOS / newer Linux and versions of fontconfig with/without the issue for others having similar issue?
In that case, I see some use of making fontconfig library search path customizable. You are welcome contributing CMake building scripts improvements to OCCT.
Mon, 08/03/2020 - 20:14
> I would say that you may build OCCT with an old (system) fontconfig and package it with the new fontconfig library, but I suppose that in your case fontconfig has different versions in SO-name, so that linker will keep looking for an older version of fontconfig?
They actually do have the same soname, so that's one path we're trying now, but these kind of things have a tendency to cause ghosty linker problems later because not every project is actually able to keep an ABI stable across its soname.
We build on CentOS 7 and have had issues with crashes on newer Ubuntu. We build on the older distro to keep libstdc++ and glibc version requirements as low as possible and to avoid making umpteen different Linux packages.
Looking, it seems CentOS 7 now actually does have 2.13, so maybe we'll be fine here after all. This might have been a bigger problem when we were back on CentOS 6 (which has 2.8.0) (and we migrated before adding occt support).
Mon, 08/03/2020 - 20:59
Tools like linuxdeployqt have decided to exclude both FreeType nor fontconfig (these should be done in sync as fontconfig depends on FreeType) from AppImage by default:
https://github.com/probonopd/linuxdeployqt/issues/261
I suppose that this might cause issues running such binaries once hypothetical FreeType 3 (aka libfreetype.7.so) will be released some day... From the other side, it doesn't look that this going to happen...
Mon, 08/03/2020 - 20:10
To add fontconfig searching routines, CMakeLists.txt should be modified with something like this (with proper system checks - to avoid looking for fontconfig on non-Linux systems):
if (USE_FREETYPE) message (STATUS "Info: Freetype is used by OCCT") OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/freetype") + OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/fontconfig")and appropriate adm/cmake/fontconfig.cmake should be created.
It may be defined from something like "glx.cmake" or more complicate like "freetype.cmake". I don't know if CMake has built-in scripts looking for fontconfig library.