The following command is generating an ACCESS DENIED in sandbox: test-flags-CC -MD This is due to the fact that the test is made with an output to /dev/null, and gcc adds the '.d' extension to the output for the -MD flag, trying to read /dev/null.d inexistant file. Output when testing ebuild: * ACCESS DENIED: fopen_wr: /dev/null.d See also sandbox.log https://633946.bugs.gentoo.org/attachment.cgi?id=498342
Is it a hypothetical failure or there is an ebuild that fails like that?
You can see the issue https://bugs.gentoo.org/633946, related to sys-boot/udk which is currently failing because of that.
Oh, so you do call '$(test-flags-CC -MD)': sys-boot/udk/udk-2015.ebuild: append-cflags $(test-flags-CC -MD) $(test-flags-CC -fshort-wchar) Note: test-flags-CC is not and will never be a complete parser of all flags for all compilers. Thus it's expected to trick the function into doing strange things by passing flags that expect parameters. I see that you wrap a lot of flags into 'test-flags-CC': local cflags_save=${CFLAGS} append-cflags $(test-flags-CC -MD) $(test-flags-CC -fshort-wchar) append-cflags $(test-flags-CC -fno-strict-aliasing) append-cflags $(test-flags-CC -nostdlib) $(test-flags-CC -c) append-cflags $(test-flags-CC -fPIC) Why do you do it? These flags are not really optional. If any of them is missing you will unlikely get a reasonable result. I would suggest passing flags as is instead without wrapping them into test-flags-CC: append-cflags -MD -fshort-wchar append-cflags -fno-strict-aliasing) append-cflags -nostdlib -c append-cflags -fPIC And so on. That ebuild uses a lot of sed. Upstream package could be improved to absorb most of what is happening in the ebuild.
I was wrapping all flags into test-flags-CC “just in case” and also because my knowledge of gcc and other C compilers is not wide enough to know which flag is present on all compilers and which is not. I understand that test-flags-CC is not to be used the way I do and will correct the ebuild for that (actually, I was about to do the modification, even if I thought it would be a workaround). Regarding upstream project, they are mostly developing for Windows and have their own vision on the way the package should be used, which is not compliant with installing it as part of a toolchain. That's why I have to do a lot of sed to adapt it to Gentoo.
(In reply to Stéphane Veyret from comment #4) > I was wrapping all flags into test-flags-CC “just in case” and also because > my knowledge of gcc and other C compilers is not wide enough to know which > flag is present on all compilers and which is not. > > I understand that test-flags-CC is not to be used the way I do and will > correct the ebuild for that (actually, I was about to do the modification, > even if I thought it would be a workaround). > > Regarding upstream project, they are mostly developing for Windows and have > their own vision on the way the package should be used, which is not > compliant with installing it as part of a toolchain. That's why I have to do > a lot of sed to adapt it to Gentoo. Yeah, that's understandable. Generally ebuild contents should not implement a build system as ebuild helpers are not very suited for that. This bug is a good example. Ideally instead of large ebuild you could structure your addition as a patch against the upstream package. Patch can live in 'files/' or be a separate small project. It could use actual "build" system out there. Like autoconf (just for makefile generation) or just an elaborate bash script that does all the required checks and generates plausible makefiles. The guideline I use: "write it as if the patch could be accepted upstream at least partially". After all Gentoo is just a distribution of what's already out there. I don't think we'll fix $(test-flags-CC -MD). You'll need to tweak the ebuild.
