Meson configuration fails due to sandbox violation

[arch1t3cht]

When configuring with Meson 63.0, the configuration crashes due to Sandbox Violations. This seems to happen in multiple CMake subprojects, since in the CI builds, different platforms show different subprojects causing the crash. See this or this CI run for detailed logs.

I confirmed locally (Windows with VS2019) that this crash only happens on Meson 63.0 - the build runs fine on Meson 62.2 and older versions, so this might also be a regression in Meson. The release notes also don't mention any changes to the sandboxing. @eli-schwartz : CoffeeFlux said to tag you for this - can you say anything more about this?

[arch1t3cht]

For posterity, here are the CI's logs for the MSVC build: msvc_ci_build.txt

[eli-schwartz]

This sounds like https://github.com/mesonbuild/meson/issues/10566

This technically both is and isn't a regression.

• It used to work, but now it doesn't.
• cmake support is considered "best effort, we hope it works" but per https://mesonbuild.com/Mixing-build-systems.html a bug in cmake support would not be considered a release blocker. We'll still try to fix it though.

The underlying issue seems to be that the cmake module's parsing of cmake subprojects and creation of an autogenerated meson.build based on it (to serialize the cmake rules into meson ones) doesn't take into account the sandbox model, and cannot really handle cmake configure_file() as a configure-time rule -- properly speaking it "should" be translated into a meson configure_file() but that's probably impossible without a hand port at which point it becomes a meson subproject instead.

Because the file is configured, it's in the build directory, but Meson expects build directory files to be passed as return values of the functions that create them, which in the case of cmake is "oh haha no actually that's not how it works, cmake is a build system not a meson function".

This can probably be fixed by our resident cmake expert / module maintainer, who I'm hoping to hear back from soon. In the meantime, I guess your options are:

• use system versions of those dependencies, e.g. by building them manually with cmake in CI, then finding them as regular dependencies
• port those subprojects to Meson, lots of work but ultimately robust
• pin meson in CI for now, and keep an eye on that ticket, then wait for a meson point release

Option 3 is likely the most appealing, although I doubt anyone would be surprised if I shill for option 2.

[CoffeeFlux]

Thanks for the explanation! I'll watch the linked issue for mensinda's response. In the meantime, option 3 sounds like the way to go.

[rcombs]

I feel like I'm missing something incredibly obvious here, but… is there a reason you can't just make a rule that shells out to cmake --build, then use the artifacts produced by that? That's how every case of one build system calling into another I've ever seen works; I don't see the point of having meson poke around at another build system's internals and try to replicate what it would've done if it'd actually been run normally.

[arch1t3cht]

The CMake subproject violation was fixed (or, well, circumvented) with Meson 0.63.1, but another violation error still remains: subprojects/luabins/src/meson.build:1:0: ERROR: Sandbox violation: Tried to grab file fwrite.c from a nested subproject.

It appears that with the new sandbox detection logic, any access to a file in the subprojects folder is a violation - even if that file does not belong to any subproject (see https://github.com/mesonbuild/meson/commit/f08aabfb77753dd7b97d3e90c0d764f3f6332dfb). Luabins is a simple subdir, but it's located in the subprojects folder, which causes the violation.

So this can be fixed by either moving subprojects/luabins back to vendor/luabins, or by turning luabins into a proper subproject. The latter option would be the nicer one, but it would require copying some of the luajit detection logic to the subproject's build file to obtain the include directory.

[eli-schwartz]

https://github.com/TypesettingTools/Aegisub/blob/8336c7d97cdec30103f301c446d7b970480abbf3/meson.build#L301

Hmmm...

BTW, I'm not sure why you need any detection logic? The luajit wrap provides a luajit dependency and that's all you need, I guess... if you want to allow finding system luajit and check that it's the right one, but fall back to the subproject, then I guess you could still use meson.override_dependency() to ensure that the subproject one takes over as the only result for dependency('luajit').

It's incorrect to pass around luajit_inc anyway:

https://github.com/TypesettingTools/Aegisub/blob/8336c7d97cdec30103f301c446d7b970480abbf3/meson.build#L296-L300

Just use

luajit_inconly = juajit_dep.partial_dependency(compile_args: true, includes: true)

But you can do that in the luabins subproject. I'm not sure why it matters in practice since it's a static library and only used in a target that adds luajit to dependencies: but there you have it.

[CoffeeFlux]

I'm not sure why you need any detection logic

A lot of distros will compile luajit without the flags we need, specifically 5.2 support.

I guess you could accomplish the same thing with override_dependency?

[stefba]

So this can be fixed by either moving subprojects/luabins back to vendor/luabins

I did it this way and adjusted the path in the meson.build file and it finally compiled. 🙏

[Siberiawind]

Update meson version from 0.63.0 to 1.0.0 can fix this problem.

[FichteFoll]

Building still fails for me with meson 1.0.0 and current master (via AUR):

==> Starting prepare()...
'subprojects/luajit' -> '../../luajit'
Re-applying patchfiles overlay for luajit...
mkdir: created directory 'subprojects/packagecache'
'subprojects/packagecache/gtest-1.8.1.zip' -> '../../../gtest-1.8.1.zip'
'subprojects/packagecache/gtest-1.8.1-1-wrap.zip' -> '../../../gtest-1.8.1-1-wrap.zip'
+ exec meson setup --prefix /usr --libexecdir lib --sbindir bin --buildtype plain --auto-features enabled --wrap-mode nodownload -D b_lto=true -D b_pie=true builddir -Dportaudio=disabled -Dopenal=disabled
The Meson build system
Version: 1.0.0
Source dir: /build/aegisub-ttools-meson-git/src/aegisub-ttools
Build dir: /build/aegisub-ttools-meson-git/src/aegisub-ttools/builddir
Build type: native build
Project name: Aegisub
Project version: 3.2.2
C compiler for the host machine: cc (gcc 12.2.1 "cc (GCC) 12.2.1 20230111")
C linker for the host machine: cc ld.bfd 2.40
C++ compiler for the host machine: c++ (gcc 12.2.1 "c++ (GCC) 12.2.1 20230111")
C++ linker for the host machine: c++ ld.bfd 2.40
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program tools/version.sh found: YES (/build/aegisub-ttools-meson-git/src/aegisub-ttools/tools/version.sh)
Found pkg-config: /usr/bin/pkg-config (1.8.0)
Run-time dependency fontconfig found: YES 2.14.2
Library m found: YES
Library dl found: YES
Run-time dependency iconv found: YES
Run-time dependency libass found: YES 0.17.0
Run-time dependency Boost (found: chrono, filesystem, locale, regex, system, thread) found: YES 1.81.0 (/usr)
Run-time dependency zlib found: YES 1.2.13
wx-config found: YES (/usr/bin/wx-config) 3.2.1
Run-time dependency WxWidgets found: YES 3.2.1
Run-time dependency icu-uc found: YES 72.1
Run-time dependency icu-i18n found: YES 72.1
Run-time dependency libpulse found: YES 16.1
Run-time dependency alsa found: YES 1.2.8
Run-time dependency ffms2 found: YES 2.40.0
Run-time dependency fftw3 found: YES 3.3.10
Run-time dependency hunspell found: YES 1.7.2
Run-time dependency uchardet found: YES 0.0.8
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency luajit found: NO (tried pkgconfig and cmake)
Message: System luajit not found; using built-in luajit

Executing subproject luajit

luajit| Project name: luajit
luajit| Project version: 2.1.0
luajit| C compiler for the host machine: cc (gcc 12.2.1 "cc (GCC) 12.2.1 20230111")
luajit| C linker for the host machine: cc ld.bfd 2.40
luajit| Library dl found: YES
luajit| Library m found: YES
luajit| Library readline found: YES
luajit| Fetching value of define "LJ_ARCH_BITS" : 64
luajit| Fetching value of define "LJ_HASJIT" : 1
luajit| Fetching value of define "LJ_HASFFI" : 1
luajit| Build targets in project: 11
luajit| Subproject luajit finished.


subprojects/luabins/src/meson.build:1:0: ERROR: Sandbox violation: Tried to grab file fwrite.c from a nested subproject.

A full log can be found at /build/aegisub-ttools-meson-git/src/aegisub-ttools/builddir/meson-logs/meson-log.txt

Edit: Applying https://github.com/tgoyne/aegisub/commit/5832ffc5122d158c6b2e601fa7b9c509be1f7169 gets through the sandbox violation but building then fails because of incompatibilities with boost 1.81.

[sl1pkn07]

hi, relating this (after apply tgoyne patch). for me, fails because meson is unable to build the rule "make luajit.h" necessary for build luajit iself

Found ninja-1.11.1 at /usr/bin/ninja
INFO: autodetecting backend as ninja                                                                                                                                                                                                                                    
INFO: calculating backend command to run: /usr/bin/ninja -C /tmp/makepkg/sl1-aegisub-git/src/aegisub/build -j 1 -v
ninja: Entering directory `/tmp/makepkg/sl1-aegisub-git/src/aegisub/build'
[1/390] /tmp/makepkg/sl1-aegisub-git/src/aegisub/tools/version.sh /tmp/makepkg/sl1-aegisub-git/src/aegisub/build /tmp/makepkg/sl1-aegisub-git/src/aegisub
[2/390] cc -Isubprojects/luajit/src/host/minilua.p -Isubprojects/luajit/src/host -I../subprojects/luajit/src/host -flto=auto -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DLUAJIT_ENABLE_LUA52COMPAT -DENDIAN_LE -DLUAJIT_OS=LUAJIT_OS_LINUX -march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIE -MD -MQ subprojects/luajit/src/host/minilua.p/minilua.c.o -MF subprojects/luajit/src/host/minilua.p/minilua.c.o.d -o subprojects/luajit/src/host/minilua.p/minilua.c.o -c ../subprojects/luajit/src/host/minilua.c
[3/390] cc  -o subprojects/luajit/src/host/minilua subprojects/luajit/src/host/minilua.p/minilua.c.o -flto -Wl,--as-needed -Wl,--no-undefined -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wl,--start-group -ldl -lm -Wl,--end-group
[4/390] /tmp/makepkg/sl1-aegisub-git/src/aegisub/build/subprojects/luajit/src/host/minilua ../subprojects/luajit/src/host/../../dynasm/dynasm.lua -D P64 -D JIT -D FFI -o subprojects/luajit/src/host/buildvm_arch.h ../subprojects/luajit/src/host/../vm_x64.dasc
[5/390] cc -Isubprojects/luajit/src/host/buildvm.p -Isubprojects/luajit/src/host -I../subprojects/luajit/src/host -Isubprojects/luajit/src -I../subprojects/luajit/src -flto=auto -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DLUAJIT_ENABLE_LUA52COMPAT -DENDIAN_LE -DLUAJIT_OS=LUAJIT_OS_LINUX -march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIE -MD -MQ subprojects/luajit/src/host/buildvm.p/buildvm.c.o -MF subprojects/luajit/src/host/buildvm.p/buildvm.c.o.d -o subprojects/luajit/src/host/buildvm.p/buildvm.c.o -c ../subprojects/luajit/src/host/buildvm.c
FAILED: subprojects/luajit/src/host/buildvm.p/buildvm.c.o 
cc -Isubprojects/luajit/src/host/buildvm.p -Isubprojects/luajit/src/host -I../subprojects/luajit/src/host -Isubprojects/luajit/src -I../subprojects/luajit/src -flto=auto -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DLUAJIT_ENABLE_LUA52COMPAT -DENDIAN_LE -DLUAJIT_OS=LUAJIT_OS_LINUX -march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIE -MD -MQ subprojects/luajit/src/host/buildvm.p/buildvm.c.o -MF subprojects/luajit/src/host/buildvm.p/buildvm.c.o.d -o subprojects/luajit/src/host/buildvm.p/buildvm.c.o -c ../subprojects/luajit/src/host/buildvm.c
../subprojects/luajit/src/host/buildvm.c:31:10: error fatal: luajit.h: No existe el fichero o el directorio
   31 | #include "luajit.h"
      |          ^~~~~~~~~~
compilación terminada.
ninja: build stopped: subcommand failed.

a workgrond is run make luajit.h beween meson setup and meson compile like:

  meson build aegisub aegisub/build
 -D somefooo

  (
  cd aegisub/subprojects/luajit/src
  make luajit.h
  )

  meson compile -C aegisub/build

after this. and apply before this patch for boost issues https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/aegisub/files/3.2.2_p20160518/aegisub-3.2.2_p20160518-fix-boost-181-build.patch. aegisub "builds ok." .. y say betheen "" because meseon configure fails when detect systemwide luajit installed, but not with the requeriments specified by aegisub. leading mix build and link with systemwide ones

sl1-aegisub-git E: Dependency luajit detected and not included (libraries ['usr/lib/libluajit-5.1.so.2'] needed in files ['usr/bin/aegisub'])

a little hack for this is:

sed "s|>=2.0.0|>=3.0.0|g" -i aegisub/meson.build

sorry, i can't found other method like cmake "-DFoo_FOUND=OFF" does but for meson

sorry if i not explain better

greetings

[arch1t3cht]

A proper fix for luajit switching to rolling releases is here https://github.com/arch1t3cht/Aegisub/commit/4a97bb0dd25cc9753b85715793f60ff8883d3430

[arch1t3cht]

The luabins sandbox violation was fixed in https://github.com/TypesettingTools/Aegisub/commit/7aa9e19a4835e7b8f1c3e2906a2942f6592f3b92 .