graphene @1.10.2 +universal: meson.build:1:0: ERROR: Compiler ccache cc can not compile programs.

[ryandesign (Ryan Carsten Schmidt)]

graphene fails to build for me on macOS 10.13.6:

The Meson build system
Version: 0.55.1
Source dir: /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_graphics_graphene/graphene/work/graphene-1.10.2-x86_64
Build dir: /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_graphics_graphene/graphene/work/build-x86_64
Build type: cross build
WARNING: Unknown options: "benchmarks"
The value of new options can be set with:
meson setup <builddir> --reconfigure -Dnew_option=new_value ...
Project name: graphene
Project version: 1.10.2
meson.build:1:0: ERROR: Compiler ccache cc can not compile programs.
A full log can be found at /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_graphics_graphene/graphene/work/build-x86_64/meson-logs/meson-log.txt

meson-log.txt says:

Sanity check compile stderr:
ccache: error: Failed to create temporary file for /opt/local/var/macports/build/.ccache/9/stats.tmp: Operation not permitted

I am using the universal variant. I don't see the problem when I don't use the universal variant.

I do have the ccache port installed but I do not have configureccache yes set in macports.conf. meson seems to be finding ccache on its own and deciding it should use it. It shouldn't do that; it should let MacPorts decide whether to use ccache. I don't know whether this is a general meson problem or is specific to how graphene is using it.

meson was recently modified to use "cross" files when building universal using the muniversal portgroup, which graphene does. Maybe that has something to do with it.

I am able to avoid the problem either by setting configureccache yes in macports.conf or by building graphene with the -t flag (since that hides ccache and other files not provided by graphene's dependencies). Deactivating ccache should also have allowed it to build.

[kencu (Ken)]

Whew! ccache with cross files... I admit, I didn't as yet consider that one.

This will take some exploring.

[kencu (Ken)]

Clues:

<​https://github.com/mesonbuild/meson/issues/1392>

<​https://github.com/mesonbuild/meson/pull/1396>

<​https://github.com/mesonbuild/meson/issues/7147>

[kencu (Ken)]

Just for a data point, I installed ccache, and then sudo port -v destroot graphene +universal did succeed for me just now.

Why I don't know.

[kencu (Ken)]

I tried this on another machine, and it all works as expected. If ccache is enabled, it is used, otherwise it is ignored. Logs attached.

[ryandesign (Ryan Carsten Schmidt)]

I usually use configureccache yes in macports.conf but I had it disabled temporarily while I noticed this problem.

I have the directory /opt/local/var/macports/build/.ccache and it is owned by macports:wheel. I don't remember whether I had to initialize it with ccache somehow or whether that happened automatically. Do you have this directory and if so is its ownership the same?

[kencu (Ken)]

this is on 10.6.8:

$ ls -la /opt/local/var/macports/build/
total 0
drwxr-xr-x   3 root      admin  102 20 Aug 10:46 .
drwxr-xr-x@ 19 root      admin  646 23 Oct  2018 ..
drwxr-xr-x  20 macports  admin  680 19 Aug 13:27 .ccache

and

$ ls -la /opt/local/var/macports/build/.ccache
total 8
drwxr-xr-x  20 macports  admin  680 19 Aug 13:27 .
drwxr-xr-x   3 root      admin  102 20 Aug 10:46 ..
drwxr-xr-x   6 macports  admin  204 19 Aug 13:27 0
drwxr-xr-x   6 macports  admin  204 19 Aug 13:27 1
drwxr-xr-x  10 macports  admin  340 19 Aug 13:27 2
drwxr-xr-x   7 macports  admin  238 19 Aug 13:27 3
drwxr-xr-x  12 macports  admin  408 19 Aug 13:27 4
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 5
drwxr-xr-x  12 macports  admin  408 19 Aug 13:27 6
drwxr-xr-x   7 macports  admin  238 19 Aug 13:27 7
drwxr-xr-x   9 macports  admin  306 19 Aug 13:27 8
drwxr-xr-x   7 macports  admin  238 19 Aug 13:27 9
drwxr-xr-x  11 macports  admin  374 19 Aug 13:27 a
drwxr-xr-x   8 macports  admin  272 19 Aug 13:27 b
drwxr-xr-x  11 macports  admin  374 19 Aug 13:27 c
-rw-r--r--   1 macports  admin   14 19 Aug 13:26 ccache.conf
drwxr-xr-x   9 macports  admin  306 19 Aug 13:27 d
drwxr-xr-x   7 macports  admin  238 19 Aug 13:27 e
drwxr-xr-x   7 macports  admin  238 19 Aug 13:27 f
drwxr-xr-x   2 macports  admin   68 19 Aug 13:27 tmp

[kencu (Ken)]

I have another idea. Do you still have cc set to point to oblivion? meson does this test compile using the build compiler.

ccache cc /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_graphics_graphene/graphene/work/build-x86_64/meson-private/sanitycheckc.c -o /opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_graphics_graphene/graphene/work/build-x86_64/meson-private/sanitycheckc.exe -pipe

We can override that by setting the CC_FOR_BUILD to ${configure.cc} but as it seems to be a throwaway test, I have not tried to sort out how we might do that as yet.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Do you still have cc set to point to oblivion?

Not at the moment, no.

[kencu (Ken)]

I see this error today building a different port:

Sanity check compile stderr:
ccache: error: Failed to create temporary file for /opt/local/var/macports/build/.ccache/4/stats.tmp: Operation not permitted

not sure why:

$ ls -la /opt/local/var/macports/build/.ccache/4
total 16
drwxr-xr-x  12 macports  admin  408 19 Aug 13:27 .
drwxr-xr-x  20 macports  admin  680 19 Aug 13:27 ..
drwxr-xr-x   3 macports  admin  102 19 Aug 13:27 2
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 3
drwxr-xr-x   3 macports  admin  102 19 Aug 13:27 5
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 9
-rw-r--r--   1 macports  admin  190 19 Aug 13:27 CACHEDIR.TAG
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 a
drwxr-xr-x   3 macports  admin  102 19 Aug 13:27 b
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 e
drwxr-xr-x   4 macports  admin  136 19 Aug 13:27 f
-rw-r--r--   1 macports  admin   67 19 Aug 13:27 stats

perhaps meson is not calling programs with the right user or permission set??

[ryandesign (Ryan Carsten Schmidt)]

There are plenty of other ports using cmake and some using autotools that see the same problem. It seems to happen when those build systems manually check for and decide to use ccache.

It's not up to meson or cmake or autotools to do anything with the user or permissions. MacPorts decides what user to use when invoking programs during the various phases of installing a port. My assumption is that because MacPorts wants to be in charge of deciding when and how programs use ccache, it is somehow preventing ports from doing so on their own.

[kencu (Ken)]

ah, thanks. Up to now I thought it had something to do with meson and in particular meson cross-building, and as I had been involved in that I felt some responsibility for sorting it out. I will leave this as is then, until someone sorts out what is to be done about such a thing.