That is mainly Clang 19 (for now), intended as a build-snaps: of Chromium and Chromium-ffmpeg.
Hi,
Can you please elaborate more on what the snap does? what issues you’re facing when trying to confine the snap? We may possibly help here to solve your issue and confine your snap
thanks
Hi, this is just LLVM but specifically the version that Chromium upstream uses. The description of the snap gives a good overview:
The LLVM that Chromium wants Chromium and Chromium-ffmpeg snaps build with LLVM, but upstream relies on bleeding edge LLVM, in particular Clang. The Ubuntu’s archive cannot keep pace with the required LLVM, so this snap builds upstream’s LLVM and is used as a ‘build-snaps:’ for both Chromium and Chromium-ffmpeg.
Previously only Chromium required this, so it was stuffed into its snapcraft.yaml, but now that Chromium-ffmpeg also needs it, it is error-prone and waste of time to maintain the code to build Chromium’s LLVM in both places. It also takes between 4 and 24 h to build on Launchpad servers so it is also a better resource-aware solution.
If the snap is confined, I just can’t use it for lack of permissions. Dropping to the shell for a test:
[The source of the project that I want to build with llvm-chromium]
../parts/chromium-ffmpeg-115541/build# ls -d */
android_webview/ codelabs/ google_update/ net/ storage/
apps/ components/ gpu/ out/ styleguide/
ash/ content/ headless/ pdf/ testing/
base/ courgette/ infra/ ppapi/ third_party/
build/ crypto/ internal/ printing/ tools/
build_overrides/ dbus/ ios/ remoting/ ui/
buildtools/ device/ ios_internal/ rlz/ url/
cc/ docs/ ipc/ sandbox/ v8/
chrome/ extensions/ media/ services/ webkit/
chromecast/ fuchsia_web/ mojo/ signing_keys/
chromeos/ gin/ native_client/ skia/
clank/ google_apis/ native_client_sdk/ sql/
[Now let's try to compile a sample program]
../parts/chromium-ffmpeg-115541/build# echo 'int main(){return 0;}' > test.cc
../parts/chromium-ffmpeg-115541/build# llvm-chromium.clang test.cc
error: error reading 'test.cc': Permission denied
1 error generated.
However I’ve been able to just sidestep the issue by invoking the binaries directly in my snaps, i.e., /snap/llvm-chromium/current/bin/clang++ instead of /snap/bin/llvm-chromium.clang++.
That also solves the
% /snap/bin/llvm-chromium.clangpp --version
cannot snap-exec: cannot exec "/snap/llvm-chromium/3/bin/clangpp": exec format error
I get with for clang++ — I cannot create an app named clang++ so I tried that clangpp as a wrapper:
# The app's command names cannot contain the plus sign
echo '"$(dirname $0)/clang++"' > third_party/llvm-build/Release+Asserts/bin/clangpp
chmod +x third_party/llvm-build/Release+Asserts/bin/clangpp
I know clang and clang++ are the same binary and apparently other than relying on argv[0], one could invoke the right driver and linker by using the right command flags but I’m not quite convinced and don’t want to rely on it.
I’m totally OK with the hack but I know it can generate reproaches (for good reason) at least on “end-user-oriented” snaps, of which this one is not the case, so I guess we can just reject this request and leave it strictly confined.
Since llvm-chromium is a compiler and requires access to arbitrary files from the host file-system (like headers and libraries etc), the requirements for classic confinement are understood (and it fits one of the supported use-cases and categories as per Process for reviewing classic confinement snaps).
I have vetted the publisher. This is now live.