While continuing working on the GS 10 port for FreeBSD, it is not fully clear to me the state of the lcms2 fork usage. I read WhyThisFork.txt and completely understand your PoV that is does not make sense to share around thread-bound data within threadsafe (shareable) objects. So you HAD to fork and solve your problem. From that I understand the vanilla version cannot be used. Confusion: configure.ac tries the bundled and forked version, but then it also allows "AC_MSG_CHECKING([for local lcms2 library source])" and then "AC_MSG_CHECKING([for system lcms2 library])". Please clarify either in WhyThisFork.txt or another better place which of those three is least or best fit to be used and what the are implications at runtime. For me it boils down to use "LIB_DEPENDS=liblcms2.so:graphics/lcms2" for the general public or not.
Note: Just had to install GS o AlmaLinux 8 and it does link dynamically to package lcms2: ======== # yum install ghostscript Last metadata expiration check: 2:32:15 ago on Thu 23 Mar 2023 13:22:12 CET. Dependencies resolved. ================================================================================ Package Arch Version Repo Size ================================================================================ Installing: ghostscript x86_64 9.27-4.el8 appstream 82 k Installing dependencies: adobe-mappings-cmap noarch 20171205-3.el8 appstream 2.1 M adobe-mappings-cmap-deprecated noarch 20171205-3.el8 appstream 118 k adobe-mappings-pdf noarch 20180407-1.el8 appstream 706 k google-droid-sans-fonts noarch 20120715-13.el8 appstream 2.5 M jbig2dec-libs x86_64 0.16-1.el8 appstream 70 k jbigkit-libs x86_64 2.1-14.el8 appstream 54 k lcms2 x86_64 2.9-2.el8 appstream 164 k ... ==========
I believe we allow the vanilla version to be used if configured. In such cases, I believe we avoid sharing profiles/links between threads. So it works correctly but uses more memory and processing power to do the same thing. So it's a choice for packagers. We'd clearly prefer people to use our bundled versions of the library (and indeed all the libraries), because that's what we test with. Different distributions have different feelings on this, so we try to accommodate them. Lots of distros (and it seems AlmaLinux is one) prefer not to see an explosion in the number of packages they have to ship, so opt to configure us to share packages. I hope this answers your question.
(In reply to Robin Watts from comment #2) > I believe we allow the vanilla version to be used if configured. In such > cases, I believe we avoid sharing profiles/links between threads. So it > works correctly but uses more memory and processing power to do the same > thing. > > So it's a choice for packagers. We'd clearly prefer people to use our > bundled versions of the library (and indeed all the libraries), because > that's what we test with. Different distributions have different feelings on > this, so we try to accommodate them. > > Lots of distros (and it seems AlmaLinux is one) prefer not to see an > explosion in the number of packages they have to ship, so opt to configure > us to share packages. > > I hope this answers your question. Yes, it absolutely does. Very much appreciated! Can you reflect this briefly in WhyThisFork.txt for others to clarify your view?