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]
/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
this doesn't happen without debug useflag due to
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
and then in the C code do
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
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
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 firstname.lastname@example.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
(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 email@example.com.
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.