When emerging recordmydesktop-0.3.8.1 the build fails with a topmost error of rmd_update_image.c:35:35: error: X11/extensions/shmstr.h: No such file or directory Reproducible: Always Steps to Reproduce: 1. emerge recordmydesktop 2. watch it fail Actual Results: The build fails. Expected Results: The build succeeds. There is a trivial workaround for this, apparently the shmstr.h file no longer comes with xextproto (I have 7.1.1 installed) but instead there is a shmproto.h file. Changing two includes from shmstr.h to shmproto.h in the source of RMD allowed the build to succeed.
Notified upstream about this.
Created attachment 209903 [details] New ebuild applying the suggested patch if necessary
Created attachment 209904 [details] Change #include
I attached the suggested patch and a new ebuild doing the patch. Probably the check for xextproto should be done in the configure step instead of the ebuild, but I guess for the time being this suffices.
=x11-misc/xvidcap-1.1.7 has exactly the same problem (X11/extensions/shmstr.h not found): (I don't know if I should open a new bug, but I think it's related enough to post here) capture.c:68:35: error: X11/extensions/shmstr.h: No such file or directory capture.c: In function ‘XGetZPixmapSHM’: capture.c:668: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token capture.c:668: error: ‘req’ undeclared (first use in this function) capture.c:668: error: (Each undeclared identifier is reported only once capture.c:668: error: for each function it appears in.) capture.c:669: error: ‘xShmGetImageReply’ undeclared (first use in this function) capture.c:669: error: expected ‘;’ before ‘rep’ capture.c:675: error: ‘sz_xShmGetImageReq’ undeclared (first use in this function) capture.c:675: error: ‘xShmGetImageReq’ undeclared (first use in this function) capture.c:675: error: expected expression before ‘)’ token capture.c:675: error: ‘X_ShmGetImage’ undeclared (first use in this function) capture.c:693: error: ‘rep’ undeclared (first use in this function) make[3]: *** [capture.o] Error 1 make[3]: *** Waiting for unfinished jobs.... mv -f .deps/codecs.Tpo .deps/codecs.Po app_data.c: In function ‘xvc_error_write_msg’: app_data.c:2474: warning: embedded ‘\0’ in format app_data.c:2481: warning: embedded ‘\0’ in format app_data.c:2500: warning: embedded ‘\0’ in format app_data.c: In function ‘error_write_action_msg’: app_data.c:2542: warning: embedded ‘\0’ in format app_data.c: In function ‘xvc_command_execute’: app_data.c:2696: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result mv -f .deps/app_data.Tpo .deps/app_data.Po make[3]: Leaving directory `/var/tmp/portage/x11-misc/xvidcap-1.1.7/work/xvidcap-1.1.7/src' make[2]: *** [all] Error 2 ...
After: /usr/include/X11/extensions # ln -s shmproto.h shmstr.h ... everything works fine.
Problem is also with xf86-video-intel (2.9.1). Tried the suggested solution by Tiago Madeira, but it didnt work and produced the following error when emerging (Fehler means error): Making all in uxa CC uxa-accel.o CC uxa-glyphs.o CC uxa-render.o CC uxa.o In file included from uxa-priv.h:331, from uxa-accel.c:33: /usr/include/xorg/shmint.h:34: Fehler: expected declaration specifiers or »...« before »ShmFuncsPtr« In file included from uxa-accel.c:33: uxa-priv.h:344: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »uxa_shm_funcs« In file included from uxa-priv.h:331, from uxa-glyphs.c:49: /usr/include/xorg/shmint.h:34: Fehler: expected declaration specifiers or »...« before »ShmFuncsPtr« In file included from uxa-glyphs.c:49: uxa-priv.h:344: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »uxa_shm_funcs« uxa-accel.c:282: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »uxa_shm_funcs«
Sebastian, I do not think your bug has anything to do with this one. Tiago, I can confirm that I have the exact same problem with xvidcap and your solution worked for me also.
(In reply to comment #6) > After: > /usr/include/X11/extensions # ln -s shmproto.h shmstr.h > > ... everything works fine. > Yeah that still works :)
Suggested patch worked for me too.
Suggested patch most likely causes the old systems to fail to build. Correct fix would involve using the autoconf macros to check for the presence of the two headers.
Fixed
