Permission denied when running compile command from console

[dprogm]

Thanks for providing this great tool!

In conjunction with clangd everything works like a charm. But I am also using other tools based on the compilation database and experience the following issue:

fatal error: opening dependency file bazel-out/k8-fastbuild/bin/external/llvm-project/llvm/_objs/Analysis/AliasAnalysis.pic.d: Permission denied

The corresponding compile command looks like this:

/usr/bin/gcc -xc++ -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -std=c++0x -MD -MF bazel-out/k8-fastbuild/bin/external/llvm-project/llvm/_objs/Analysis/AliasAnalysis.pic.d -frandom-seed=bazel-out/k8-fastbuild/bin/external/llvm-project/llvm/_objs/Analysis/AliasAnalysis.pic.o -fPIC -DLLVM_ON_UNIX=1 -DHAVE_BACKTRACE=1 -DBACKTRACE_HEADER=<execinfo.h> -DLTDL_SHLIB_EXT=".so" -DLLVM_PLUGIN_EXT=".so" -DLLVM_ENABLE_THREADS=1 -DHAVE_DEREGISTER_FRAME=1 -DHAVE_LIBPTHREAD=1 -DHAVE_PTHREAD_GETNAME_NP=1 -DHAVE_PTHREAD_H=1 -DHAVE_PTHREAD_SETNAME_NP=1 -DHAVE_REGISTER_FRAME=1 -DHAVE_SETENV_R=1 -DHAVE_STRERROR_R=1 -DHAVE_SYSEXITS_H=1 -DHAVE_UNISTD_H=1 -D_GNU_SOURCE -DHAVE_LINK_H=1 -DHAVE_MALLINFO=1 -DHAVE_SBRK=1 -DHAVE_STRUCT_STAT_ST_MTIM_TV_NSEC=1 -DLLVM_NATIVE_ARCH="X86" -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -DLLVM_NATIVE_TARGETMCA=LLVMInitializeX86TargetMCA -DLLVM_HOST_TRIPLE="x86_64-unknown-linux-gnu" -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" -DLLVM_VERSION_MAJOR=18 -DLLVM_VERSION_MINOR=0 -DLLVM_VERSION_PATCH=0 -DLLVM_VERSION_STRING="18.0.0git" -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DLLVM_ENABLE_ZLIB=1 -DLLVM_ENABLE_ZSTD=1 -DZSTD_MULTITHREAD -DBLAKE3_USE_NEON=0 -DBAZEL_CURRENT_REPOSITORY="llvm-project" -iquote external/llvm-project -iquote bazel-out/k8-fastbuild/bin/external/llvm-project -iquote external/llvm_zlib -iquote bazel-out/k8-fastbuild/bin/external/llvm_zlib -iquote external/llvm_zstd -iquote bazel-out/k8-fastbuild/bin/external/llvm_zstd -Ibazel-out/k8-fastbuild/bin/external/llvm_zlib/_virtual_includes/zlib -Ibazel-out/k8-fastbuild/bin/external/llvm_zstd/_virtual_includes/zstd -isystem external/llvm-project/llvm/include -isystem bazel-out/k8-fastbuild/bin/external/llvm-project/llvm/include -Wno-deprecated -Wno-unused-parameter -Wno-comment -Wno-maybe-uninitialized -Wno-misleading-indentation -std=c++17 -Wno-class-memaccess -Wno-builtin-macro-redefined -D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted" external/llvm-project/llvm/lib/Analysis/AliasAnalysis.cpp -g -S

Changing the permissions fixes the problem.

[cpsauer]

Hey Dirk--sorry I've been so slow on this. I've had some urgent things I've needed to do, so I had to step away for a little bit.

I wish I had better news, but I've honestly got no idea what's causing this off the top of my head, and I'm not sure I've got comparative advantage over you without (a lot) more information.

Did you make any progress in figuring it out? If you run the compile command separately, does it produce a file with problematic permissions? Any idea where the problematic permissions are coming from or what they are?

(I'm not sure how to explain everything working for clangd but not for other tool, since I'd think they'd just both be operating on the output file--except that significant caching goes on around the use of the .d files, so subsequent runs may well not hit them if nothing has changed. To reset those caches you can rm bazel-out/**/*.hedron.compile-commands.headers.)

[dprogm]

@cpsauer Thank you for the reply. I am going to investigate this further the next days and try to answer your questions. The error is caused by the preprocessor compiler flag -MF <file>. The compiler cannot open this file because of these file permissions (no write permission). I am not sure how clangd handles such kind of flag. Maybe this is just an issue of the tooling.

TODO list for me:

• [ ] Document the file permissions here in the issue description
• [ ] Figure out how clangd handles this flag

[cpsauer]

Ooh, I see. Right, so Bazel must be marking all its cached outputs as readonly when it runs its actions--preventing people from easily changing them and messing up the cache. And then rerunning the command fails because it tries to overwrite. That all makes sense.

This tool actually reads those .d files when available, but there isn't an issue because it's only reading. I'd imagine clangd does the same--or just ignores those dependency file output flags.

To take a step back: What are these other tools that want to overwrite those bazel dependency file outputs? And are you sure you want them to?

[cpsauer]

^ Dirk, any thoughts here?

[dprogm]

@cpsauer I didn't forget about it. But as you pointed out, this might be an issue primarily caused by the dependent tooling. Because Bazel is setting these permissions I don't see a clean way to circumvent it. I am using the VS Code Compiler Explorer Extension that relies on the compilation database. But I am going to create a PR with a fix (filter out such kind of flags) to this repository.

Sorry for taking up your time. But I think we can close this :wink:

[cpsauer]

Thanks for taking the time to write in--and to leave things better than you found them.

I'm wondering if, maybe, the PR might be better placed with the other tool? I assume it's reading the .d dependency files because it's getting some value out of them (like we do!), so perhaps it could open files in read-only mode? (Either always, or as necessary.) Or if not, it could ignore the flags over there?

Sounds like I should close, so I will, but ofc feel free to write me back. Happy coding!