Created attachment 422054 [details] output of emerge --info I stepped into this one while debugging firefox. output of emerge -pv mesa Calculating dependencies... done! [ebuild R ] media-libs/mesa-11.0.6::gentoo USE="classic debug* dri3 egl gallium gbm llvm nptl pax_kernel pic udev -bindist -d3d9 -gles1 -gles2 -opencl (-openmax) -osmesa (-selinux) -vaapi (-vdpau) -wayland -xa -xvmc" VIDEO_CARDS="nouveau (-freedreno) -i915 -i965 -ilo -intel -r100 -r200 -r300 -r600 -radeon -radeonsi (-vmware)" 0 KiB
Created attachment 422056 [details] compressed build.log /var/tmp/portage/media-libs/mesa-11.0.6/work/mesa-11.0.6/src/mapi/glapi/glapi_gentable.c:44:22: fatal error: execinfo.h: No such file or directory #include <execinfo.h> this doesn't happen without debug useflag due to #ifdef USE_BACKTRACE #include <execinfo.h> #endif in glapi_gentable.c
A similar issue came up with uclibc. Take a look at bug #425042. I approached the problem incorrectly there and fell into the trap of checking for __GLIBC__ and __UCLIBC__ which is what most code does. But this is wrong minded and musl doesn't define a __MUSL__ on purpose. The proper way to fix this is to check for execinfo.h in configure.ac, set some #define and then check for it in the code. So, in the configure file do AC_CHECK_HEADERS([execinfo.h]) and then in the C code do #ifdef HAVE_EXECINFO_H ... #endif Make sure that config.h is included at the top of the C. Of course, make sure to rip out any of the __GLIBC__ and __UCLIBC__ that are trying to protect the backtrace code. If you like and you find it fun, try making a patch and we'll submit it upstream.
Created attachment 422744 [details, diff] patch to ad header-check This is a patch to implement a check for the presence of execinfo.h during configure. I'm not yet really sure about the rest though.
Created attachment 422746 [details, diff] patch to eventually bypass the bug This is what Felix suggested to do. It seems to fix the compile issue for me, but I have no idea what it would do on a glibc system or if it would suit upstream.
(In reply to tt_1 from comment #4) > Created attachment 422746 [details, diff] [details, diff] > patch to eventually bypass the bug > > This is what Felix suggested to do. It seems to fix the compile issue for > me, but I have no idea what it would do on a glibc system or if it would > suit upstream. That patch should be fine on all systems. Build systems should move away from __CYGWIN__ style check and to direct checks of the components they need. The best example here is __UCLIBC__ where checking if that macro is defined is deceiving since uclibc is configurable. So some uclibc systems might HAVE_EXECINFO_H while others might not. Testing for __UCLIBC__ when you want to know if you HAVE_EXECINFO_H is wrong minded. I've been guilty of this myself.
(In reply to tt_1 from comment #3) > Created attachment 422744 [details, diff] [details, diff] > patch to ad header-check > > This is a patch to implement a check for the presence of execinfo.h during > configure. I'm not yet really sure about the rest though. It is sufficient to do just +AC_CHECK_HEADERS([execinfo.h]) since if this macro passes, then it defines HAVE_EXECINFO_H for you. Check that it works though since there might be some subtlety.
Created attachment 425000 [details] patch ready for upstrem like this?
Created attachment 425006 [details, diff] diff for the ebuild the ebuild needs a little adjustment
Created attachment 427852 [details, diff] mesa-11.1.2 and mesa-11.0.6 execinfo patch Here's a modified version of @tt_1's patch that removes the old __GLIBC__ && !__UCLIBC__ checks.
wrt Comment 9: I don't think it's necessary to patch intel_regions.c. The code is essentially commented out. Except for that it looks good to me. With the part for glapi_gentable.c removed (glapi_gentable.c is generated by gl_gentable.py), the patch applies cleanly to mesa git. It would be cool if you could git-send-email it to mesa-dev@lists.freedesktop.org. wrt Comment 6: AC_CHECK_HEADERS will define HAVE_EXECINFO_H make configure.status substitute HAVE_EXECINFO_H everywhere, but that's it, since there is no configure header.
(In reply to Felix Janda from comment #10) > wrt Comment 9: > I don't think it's necessary to patch intel_regions.c. The code is > essentially commented out. Except for that it looks good to me. With > the part for glapi_gentable.c removed (glapi_gentable.c is generated > by gl_gentable.py), the patch applies cleanly to mesa git. It would be > cool if you could git-send-email it to mesa-dev@lists.freedesktop.org. Alright. I'll remove those pieces and submit it upstream.
What happened with the patch? Has it been sent to upstream?
I submitted it, and it was ignored -- I'm not sure how to get the maintainers to notice it.
Aric, thanks for submitting the patch upstream! (It can be seen here: https://patchwork.freedesktop.org/patch/76803/) https://mesa.freedesktop.org/submittingpatches.html has some advice on submitting patches. (Check out scripts/get_reviewer.pl.)
(In reply to Aric Belsito from comment #13) > I submitted it, and it was ignored -- I'm not sure how to get the > maintainers to notice it. mattst88 might be able to help you. i think he's upstream with mesa.
Mesa no longer includes execinfo.h: % git grep execinfo docs/relnotes/19.1.2.rst:- meson: Search for execinfo.h docs/relnotes/21.3.0.rst:- util/u_debug_symbol: remove debug_symbol_name_glibc and execinfo dependency docs/relnotes/21.3.0.rst:- meson: stop searching for execinfo
