Re: pkg/57517: inconsistent freetype2 and fontconfig

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

The following reply was made to PR pkg/57517; it has been noted by GNATS.

From: David Holland <dholland-pkgtech%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/57517: inconsistent freetype2 and fontconfig
Date: Wed, 10 Jul 2024 23:18:29 +0000

 Since there's been no movement, here's a copy of what I posted to
 tech-pkg.
 
    ------
 
 From: David Holland <dholland-pkgtech%netbsd.org@localhost>
 To: tech-pkg%netbsd.org@localhost
 Subject: transitive builtin logic is busted
 Date: Sat, 25 May 2024 23:37:14 +0000
 
 Today because of another failure I happened to notice that I was
 getting this:
 
    % make show-var VARNAME=USE_BUILTIN.fontconfig
    no
    % ls -l work/.buildlink/lib/libfontconfig.so
    lrwxr-xr-x  1 dholland  people  31 May 25 02:58 work/.buildlink/lib/libfontconfig.so -> /usr/X11R7/lib/libfontconfig.so
 
 IOW, it was supposedly not using the builtin fontconfig, but was
 buildlinking its files anyway instead of the pkgsrc version.
 
 This then causes everything downstream of fontconfig to be linked
 against two versions of freetype2, and things go downhill. (Though the
 native and pkgsrc versions of freetype2 are not very different and
 it's possible that there's no overt fallout or it's rare.)
 
 This turns out to be caused by the following:
 
    - fontconfig's builtin.mk sets USE_BUILTIN.fontconfig to yes
      because there's no local reason not to;
    - this causes mk/x11.builtin.mk, when included by fontconfig's
      builtin.mk, to set BUILDLINK_PREFIX.fontconfig to $(X11BASE);
    - the transitivity logic in bsd.buildlink3.mk then sets
      USE_BUILTIN.fontconfig to no because of freetype2;
    - the logic further down in bsd.buildlink3.mk for setting
      BUILDLINK_PREFIX.fontconfig is skipped because it's already
      set;
    - later on the buildlink logic itself symlinks files from the
      wrong prefix, and then that's what's used to build.
 
 I have no idea when this broke; it could have been some time ago. (I
 do remember a few months back running into a report that something
 seemed to be wrong with the transitivity logic, but I can't remember
 whose report or what it was about, or where I saw it.)
 
 x11.builtin.mk hasn't been changed in forever and the relevant
 BUILDLINK_PREFIX logic in bsd.buildlink3.mk hasn't changed recently
 either, and I doubt there have been major changes to the ordering of
 things.
 
 But, it did work once upon a time... anyway, the question is how to
 fix it.
 
 For the moment I've done this locally, which is enough to get my
 builds to work, but it doesn't seem in any way like the right thing.
 Ideas welcome...
 
 Index: bsd.buildlink3.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/buildlink3/bsd.buildlink3.mk,v
 retrieving revision 1.263
 diff -u -r1.263 bsd.buildlink3.mk
 --- bsd.buildlink3.mk	13 Jan 2024 20:26:47 -0000	1.263
 +++ bsd.buildlink3.mk	25 May 2024 23:34:15 -0000
 @@ -135,6 +135,9 @@
  .      if ${_ok_} != yes
           # not ok for it to be builtin; force it to pkgsrc
           USE_BUILTIN.${_pkg_:S/^-//}:=no
 +         # If the buildlink prefix is already set, clear it or we'll
 +         # buildlink the wrong files. XXX: this is a hack
 +.        undef BUILDLINK_PREFIX.${_pkg_:S/^-//}
           FORCED_PKGSRC+=${_pkg_:S/^-//}
           # using += here fails to evaluate ${_ok_} until after the loop
           FORCED_PKGSRC_REASONS:=${FORCED_PKGSRC_REASONS} ${_pkg_:S/^-//}:${_ok_:S/^no,//}
 
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost