pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On 24.02.2020 22:46, Sad Clouds wrote:
On Mon, 24 Feb 2020 21:55:24 +0100
Roland Illig <> 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

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 \

edit ~/sym-link/etc/mk.conf:
WRKOBJDIR=              /home/rillig/tmp/sym-work
PACKAGES=               /home/rillig/sym-packages
PKG_DEVELOPER=          yes
MAKE_JOBS=              8
BUILD_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/ 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

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.

diff -u -p -r1.31
--- mk/	7 May 2019 19:36:43 -0000	1.31
+++ 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}}

Home | Main Index | Thread Index | Old Index