Re: x11/gtk3 - fatal error: pango/pango.h: No such file or directory

[Roland Illig <roland.illig%gmx.de@localhost>]

On 24.02.2020 22:46, Sad Clouds wrote:
> On Mon, 24 Feb 2020 21:55:24 +0100
> Roland Illig <roland.illig%gmx.de@localhost> wrote:
> > In the second of these configurations, the buildlink wrappers that
> > install the headers and libraries into WRKDIR/.buildlink during a
> > package build will just skip these.

That was wrong. The buildlink wrappers installed the symlinks. The part
that really hid the headers was the cwrapper.

> /usr/pkg -> /opt/pkg
> LOCALBASE=       /usr/pkg
>
> Suspect something is not buildlinking properly, but why is this an
> issue now? Is it not possible to have buildlink wrappers dereference
> symlink that is LOCALBASE? Symlinks are supposed to be transparent to
> applications.

I investigated this issue by disabling the symlink check in
bootstrap/bootstrap. After that:

mkdir ~/sym-target
ln -s sym-target ~/sym-link

~/proj/pkgsrc/bootstrap/bootstrap \
    --unprivileged \
    --prefix=$HOME/sym-link

edit ~/sym-link/etc/mk.conf:
WRKOBJDIR=              /home/rillig/tmp/sym-work
PACKAGES=               /home/rillig/sym-packages
PKG_DEVELOPER=          yes
ALLOW_VULNERABLE_PACKAGES= yes
CREATE_WRKDIR_SYMLINK=  yes
MAKE_JOBS=              8
BUILD_ENV_SHELL=        bash
CONFIGURE_ENV_SHELL=    bash

cd ~/proj/pkgsrc/x11/gtk3
~/sym-link/bin/bmake update

It took a while until the first package failed to build. It was
devel/at-spi2-core, which couldn't find the dbus.h header. I dug deep
down into the tools that build the package: meson, ninja, g-ir-scanner, cpp.

I noticed some duplicate lines in WRKDIR/.cwrapper/config/*, patched
mk/cwrappers.mk with the appended patch and defined
ABS_LOCALBASE=/home/rillig/sym-target in mk.conf. After that, I cleaned
up the working directories and tried again. This time the package built
fine.

The patch is only a proof-of-concept. I don't really like to have the
variable ABS_LOCALBASE defined, and I also want to avoid calling
realpath(1) repeatedly since the majority of pkgsrc setups does not need
this. But as a local workaround it works fine.

> It's not a major issue, I can just change LOCALBASE to /opt/pkg. I'm
> just curious as to what has changed over the years, it seems like a bug
> or design issue.

I'm not sure whether my patch is a good fix or if there are other even
more subtle side-effects of using symlinks. There probably are, and to
track these down, the pkgsrc infrastructure would need some additional
code to check for any likely inconsistencies.

Therefore it looks sensible to me that it's easier to disallow symlinks
at all. It just removes one source of confusion from the already
complicated domain of building software.

Roland

diff -u -p -r1.31 cwrappers.mk
--- mk/cwrappers.mk	7 May 2019 19:36:43 -0000	1.31
+++ mk/cwrappers.mk	25 Feb 2020 06:15:16 -0000
@@ -73,8 +73,11 @@ generate-cwrappers:
 .  for cmd in ${WRAPPER_REORDER_CMDS}
 	${RUN}echo reorder=${cmd:S/^reorder://:Q} >> ${CWRAPPERS_CONFIG_DIR}/${CWRAPPERS_CONFIG.${wrappee}}
 .  endfor
-.  for cmd in ${CWRAPPERS_TRANSFORM.${wrappee}} ${_CWRAPPERS_TRANSFORM}
-	${RUN}echo transform=${cmd:u:Q} >> ${CWRAPPERS_CONFIG_DIR}/${CWRAPPERS_CONFIG.${wrappee}}
+.  for cmd in ${CWRAPPERS_TRANSFORM.${wrappee}:u} ${_CWRAPPERS_TRANSFORM:u}
+	${RUN}echo transform=${cmd:Q} >> ${CWRAPPERS_CONFIG_DIR}/${CWRAPPERS_CONFIG.${wrappee}}
+.    if ${ABS_LOCALBASE:U} && ${cmd:M*${LOCALBASE}*}
+	${RUN}echo transform=${cmd:S,${LOCALBASE},${ABS_LOCALBASE},1:Q} >> ${CWRAPPERS_CONFIG_DIR}/${CWRAPPERS_CONFIG.${wrappee}}
+.    endif
 .  endfor
 .  for cmd in ${CWRAPPERS_APPEND.${wrappee}:U}
 	${RUN}echo append=${cmd:Q} >> ${CWRAPPERS_CONFIG_DIR}/${CWRAPPERS_CONFIG.${wrappee}}