I will try the newer upstream version, I just didn't want to get into recreating a complex patch file.

Updated to use upstream 2.3.8 version. Only tested on Intel 15.X system

After reading the shlibs policy, I am not sure why this package would be compatibility version 6.0.0 vs 5.0.0 and not 2.0.0. What sets that version number? Is it just an incremented value as the shlib version is changed? Why would it be a major change instead of a minor change to reflect the actual code revision version?

The compatibility version is whatever otool -L says it is, which is set upstream in the code, so not really within the powers of our packaging policy. When and how upstream developers decide to increment it is usually beyond my understanding, so I generally build with fink --validate.

Is the spacing bug mentioned in the unpatched .info (now at https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/1 ) fixed? @dmacks

ETA: noticed @dhomeier saying https://bugs.freedesktop.org/show_bug.cgi?id=47178 was fixed. That bug was only closed because upstream moved from bugzilla to gitlab. The moved current bug URL is at my link above.

Doesn't matter since I think the NULL fix is fine, but upstream changed it to 0, rather than typing it.
https://gitlab.freedesktop.org/xorg/lib/libxft/-/commit/9c23173cf1ff861bdb8538e3aa21ec509b0d87d8

I cherry picked the first commit (NULL fix) and applied it to master.

I thought I had reverted everything except the NULL fix. But anyway, thanks, and I think which value is cast to what is irrelevant. I personally prefer keeping the NULL for readability of the code, but YMMV.

Yeah, I don't care if it's a typed NULL or 0. Anyway, I have no idea why this PR shows conflicts since I specifically cherry picked the first commit in the PR.

I see the difference, the update to the newer upstream as suggested by dhomeier was rejected. 2.3.8 vs 2.3.0

Been traveling, seems like I didn't push the reversion to the previous Shlibs def. Now done.

From the build output during deb file validation at the end:

Validating .deb dir /opt/sw/build.build/root-xft2-shlibs-2.3.8-1...
Error: Shlibs field says compatibility version for /opt/sw/lib/xft2/lib/libXft.2.dylib is 5.0.0, but it is actually 6.0.0.

The values before 928321f were actually correct.

The previous ones were those for 2.3.8, these are now the 2.2.0 ones again, but I thought the update to 2.3.8 was rejected since it is not clear if the spacing problem in https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/1 has really been fixed?
There is one newer commit https://gitlab.freedesktop.org/xorg/lib/libxft/-/commit/3ca7a7c that sounds like it might be dealing with it, but I haven't been able to confirm that – did not notice any fonts problems with my xterm, but it does not look like that is linking xft2.

I did build mrxvt now once against the 2.2.0 version from your initial commit, and against 2.3.8 without the patches, and cannot see any differences in font spacings or other issues between the two:

So updating might be OK? Also built on 10.14 with Xcode 11.3 without the patchfile.

Set compatibility version to 6.0.0 as tool declares it
Resolved merge with master, this should be working.

% otool -L /opt/sw/lib/xft2/lib/libXft.2.3.8.dylib
/opt/sw/lib/xft2/lib/libXft.2.3.8.dylib:
/opt/sw/lib/xft2/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.8.0)

Should be good to go?

Patchfile necessary for stringent compiler on Sequoia

ping?

version 2.3.8 builds just fine with the edit I listed above. However that small tweak upstream update to version 2.3.9 does not build. It is looking for xproto and xrender which appear to be virtual packages that are installed. Looks like the correct PKG_CONFIG_PATH is set.

Is this because it is using ppkg-config and not system-pkgconfig which does not provide xrender and xproto?

checking whether make supports nested variables... (cached) yes
checking for xrender >= 0.8.2 x11 xproto >= 7.0.22... no
configure: error: Package requirements (xrender >= 0.8.2 x11 xproto >= 7.0.22) were not met:

Can't find xrender >= 0.8.2 x11 xproto.pc in any of /opt/sw/lib/pkgconfig /opt/sw/share/pkgconfig /opt/X11/lib/pkgconfig /opt/X11/share/pkgconfig /usr/X11/lib/pkgconfig /usr/X11/share/pkgconfig /usr/lib/pkgconfig /usr/share/pkgconfig
use the PKG_CONFIG_PATH environment variable, or
specify extra search paths via 'search_paths'

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XRENDER_CFLAGS
and XRENDER_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
### execution of /tmp/fink.mH0FZ failed, exit code 1

and listing of libraries:

%  fink list xrender xproto
Information about 16257 packages read in 2 seconds.
 i   system-pkgconfig-cairo-xlib-xrender                      1.17.4-1                                   [virtual pkgconfig package representing cairo-xlib-xrender]
 i   system-pkgconfig-dmxproto                                2.3.1-1                                    [virtual pkgconfig package representing dmxproto]
 i   system-pkgconfig-xproto                                  7.0.33-1                                   [virtual pkgconfig package representing xproto]
 i   system-pkgconfig-xrender                                 0.9.10-1                                   [virtual pkgconfig package representing xrender]
% 

$ grep Version: /opt/X11/lib/pkgconfig/xrender.pc /opt/X11/share/pkgconfig/xproto.pc /opt/X11/share/pkgconfig/renderproto.pc 
/opt/X11/lib/pkgconfig/xrender.pc:Version: 0.9.11
/opt/X11/share/pkgconfig/xproto.pc:Version: 7.0.33
/opt/X11/share/pkgconfig/renderproto.pc:Version: 0.11.1

renderproto is a dependency of xrender, so I included it in the debug.

This is with Xquartz 2.8.5. Your fink list output indicates a slightly older version, but the virtual packages should still satisfy what ppkg-config is looking for (ppkg-config is just a different tool to read .pc files). system-pkgconfig-FOO is the name of a virtual package that Fink creates to identify having a specific .pc available from Xquartz.

Try manually running the detections one by one to see which one breaks and if there are more details:

ppkg-config --cflags "xrender >= 0.8.2"
ppkg-config --cflags "x11"
ppkg-config --cflags "xproto >= 7.0.22"
ppkg-config --cflags "renderproto >= 0.9"

They should all output -I/opt/X11/include

They should all output -I/opt/X11/include
And they all do list that. How ever my Xquartz is old (2.8.2)
The versions are all the same except xrender.pc shows version 0.9.10 which should satisfy the requirement
I reinstalled Xquartz (same version) and the file exists /opt/X11/include/X11/extensions/Xrender.h and Xproto.h

I seem to have two different versions of xproto.pc ??? But either one should satisfy the dependency.

% diff /opt/X11/lib/pkgconfig/xproto.pc /opt/X11/share/pkgconfig/xproto.pc
2,3d1
< exec_prefix=${prefix}
< libdir=${exec_prefix}/lib
9c7
< Version: 7.0.31
---
> Version: 7.0.33

I am going to remove Xquartz as much as I can and reinstall.

Removing all X11 and reinstalling Xquartz 2.8.5 still has package not found.
all four of the individual tests give -I/opt/X11/include
The ppkg-config command returns that the package exists

% ppkg-config --exists "xrender >= 0.8.2"
% echo $?
0

It's a bug in ppkg-config. Will look into it....

It's a bug in ppkg-config. Will look into it....

PerlPkgConfig/perl-PkgConfig#63

Ok, that is why I seem to be beating my head against a wall. Thanks for that info.

The ppkg-config bug can be worked-around by a patch to ./configure, but more generally #923/#1254 is the robust solution.

Probably need to wait until pkgconf is released, but since it is broken anyway.....
Updated to use pkgconf instead of ppkg-config, avoid command line bug in ppkg-config
Updated Shlibs to version 6.0 for library versions >= 2.3.8
Builds in maintainer mode

As an intermediate data point I've built and installed the pkgconf from #1254 and successfully built some packages like the new openssl350 with it on Big Sur 11.7, but am completely stuck in conflicting dependency hell before I can even attempt to build this package, as already fontconfig2 or freetype219 are pulling this in:

The following package will be installed or updated:
 xft2-dev
The following 76 additional packages will be installed:
 blt-dev blt-shlibs cairo cairo-shlibs cmake doxygen fontconfig-config fontconfig2-dev fontconfig2-shlibs freeglut2 freeglut2-shlibs freetype219
 freetype219-shlibs gd3 gd3-shlibs ghostscript gnutls30-3.7 gnutls30-3.7-shlibs groff gsasl19-dev gsasl19-shlibs gtk-doc itstool json-c5 json-c5-shlibs lcms2
 lcms2-shlibs libbrotli1 libbrotli1-shlibs libcurl4 libcurl4-shlibs libgraphite2-dev libgraphite2-shlibs libharfbuzz0-dev libharfbuzz0-shlibs libheif1-dev
 libheif1-shlibs libidn libidn-shlibs libjasper7 libjasper7-shlibs libjpeg8.2-turbo libjpeg8.2-turbo-shlibs liblerc4 liblerc4-shlibs libopenjp2.7
 libopenjp2.7-shlibs libraqm0-dev libraqm0-shlibs librtmp1 librtmp1-shlibs libtiff6 libtiff6-shlibs libwebp7 libwebp7-shlibs libwoff2-1.0.2-dev
 libwoff2-1.0.2-shlibs libx265.192-dev libx265.192-shlibs libxml2-py310 netpbm-bin netpbm11-shlibs openjpeg-bin openldap2-dev openldap2-shlibs
 openmotif4-2level openmotif4-2level-common openmotif4-2level-shlibs openssl300-dev python310 python310-shlibs tcltk tcltk-dev tcltk-shlibs texlive-base
 xft2-shlibs
The following 2 packages might be temporarily removed:
 freeglut2 libjpeg9
Default answer will be chosen in 60 seconds...
Do you want to continue? [Y/n] 
Reading buildlock packages...
	All buildlocks accounted for.
/opt/sw2/bin/dpkg-lockwait -i /opt/sw2/fink/dists/stable/main/binary-darwin-x86_64/crypto/openssl300-dev_3.0.16-1_darwin-x86_64.deb
Selecting previously unselected package openssl300-dev.
dpkg: considering removing openssl110-dev in favour of openssl300-dev ...
dpkg: yes, will remove openssl110-dev in favour of openssl300-dev
(Reading database ... 225305 files and directories currently installed.)
Preparing to unpack .../openssl300-dev_3.0.16-1_darwin-x86_64.deb ...
Unpacking openssl300-dev (3.0.16-1) ...
Setting up openssl300-dev (3.0.16-1) ...
Processing triggers for dpkg-base-files (0.4-1) ...
Clearing dependency_libs of .la files in /opt/sw2/lib ...
Failed: Problem resolving dependencies. Check for circular dependencies.

I don't have the time or nerve to figure out which of the 76 packages may be built on either openssl300-dev or openssl110-dev only (virtually everything seems to be pulling in texlive-base and ghostscript with their full host already), but willing to continue with a pointer on how to proceed.

From that list of packages, I suspect it's #1246. @nieder has a proposed change that could fix it (#1246 (comment)).

Thanks, will have an eye on that. In fact, recalling fink list --format=dotty-build --recursive turned out that the only openssl110 dependency is python310, but trying to replace that with the openssl300-build from #996 lets it directly fail with
Failed: Problem resolving dependencies. Check for circular dependencies.

pkgconf (PR #1254) is pushed. You can either use it directly (dependency on 'pkgconf' and passing bin/pkgconf as the pkg-config executable by whatever means) or a dependency on 'pkgconfig (>= 1.0)', which supplies the default executable location bin/pkg-config as a wrapper around bin/pkgconf. I pushed the latter to the existing xft2-dev.info via ada38da

sounds good. I am on travel for the next couple of weeks so I will pick up when I return.

Enjoy! I just got back from vacay (I think that's what the cool kids call it) a few days ago.

Part vacay, part work, just saw my daughter graduated, visiting relatives, then a week of work at Los Alamos lab and then a week of more vacay...

Thanks all! I've squash-merged this PR (some parts had already been pushed, so that was easiest fix for the conflicts).

Now that pkgconfig is actually pkgconf, we also don't need any special hackery regarding that. If user already has old pkgconfig installed, that's sufficient; if they try to install pkgconfig now they get pkgconf, and don't need a special path to it.