When compiling mesa-22.2.3 using clang, one will get errors due to non conformance to C 2x standard, ie passing arguments to functions with no prototype. The following patch fixes the issue. Note: this has not been checked using gcc Reproducible: Always Steps to Reproduce: 1.Try to build mesa-22.2.3 using clang with a configuration using gallium (amdgpu in my case) 2. Build fails while trying to compile src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 3. Actual Results: build fails while trying to compile src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x Expected Results: build to succeed
Created attachment 843289 [details] output from emerge --info =media-libs/mesa-22.2.3
Created attachment 843291 [details, diff] proposed patch fixing C2x standard conformance
Can you send the patch upstream to Mesa please and pop the link here? Thanks.
Of course, here you are: <https://gitlab.freedesktop.org/mesa/mesa/-/issues/7919>
Comment on the upstream issue from 9 months ago: > Feel free to sent MR. And from 6 months ago: > @JocelynM please post your patch as a merge request (see help page if you don't know how) so that we can review & merge it :)
From the emerge --info output > sys-devel/clang: 15.0.3::fixes > [...] > sys-devel/lld: 15.0.3::fixes > sys-devel/llvm: 15.0.3::fixes And > media-libs/mesa-22.2.3::fixes was built with the following: You should not report bugs against packages when your ebuild comes from some other overlay that we have no control over or insight into. Also > USE="-X clang -d3d9 -debug gles1 gles2 libcxx llvm lm-sensors -lto media-libs/mesa has never had IUSE=lto. pipe_loader_sw.c builds fine for me with clang-16 and mesa-23.2.1. I believe your issue was resolved by upstream commit fb6b3bee251 ("loader: fixes -Werror,-Wdeprecated-non-prototype for clang-15 in pipe-loader") which was in mesa-23.0.0.
First of all, I confirm that this issue report is now pointless, fixed upstream. Sorry that I never saw any notification about the merge request upstream. Sorry also I did noticed here the patch had become obsolete while switching to 22.3.x version (as it seems from my repo history), as I should have done... > You should not report bugs against packages when your ebuild comes from some > other overlay that we have no control over or insight into. I understand your point of view but I can see no other way to easily test fixes than having a "fixes" overlay for it. Patches in the gentoo ebuild repository would be discarded by every emaint sync Using git does not allow to easily check the building behavior differences between the "fixed" ebuild and the "vanilla" one, thus check if any patch is still required or may be changed or simplified. Then, when I post a patch here from my "fixes" repository, this just reflects the difference I presume required to solve an issue. > media-libs/mesa has never had IUSE=lto. This is correct. Here's an explanation why this happens here: It happens that gcc have many issues with lto when dealing with C++ langage when clang usually has not. In the gentoo repository, there are many non-conditional "filter-lto" added when this is actually needed only if using gcc for build. There still are a few package needing to always be compiled using "-fno-lto", whatever the compiler. As LTO can bring useful performance improvements, my like is to try to use it each time it's possible, thus selecting clang compiler instead of disabling this optimisation. As stdc++ / libc++ ABI have some incompatibilities, the choice of gcc or clang shall be propagated to dependencies. I made the choice of checking every package using C++ langage, defining CXX="/bin/false" in my make.conf Then, I added a small eclass in my fixes repository, called toolchain-select, adding 3 IUSE flags: » clang, in order to select gcc / binutils or LLVM / clang / lld toolchain then the proper build flags, as gcc and clang optimization flags are not always compatible » libcxx, in order to avoid libc++ incompatibilities when linking a gcc built package against a clang built library. A better solution should be found for this, avoiding this kind of mix in every case. I have to check on all my running machines but as far as I remember, it's not actually used anymore. » lto, in order to filter any "-flto.*" flags and add "-fno-lto" for the few packages which seems to require it, as I got "-flto=full" in my make.conf
