Created attachment 21276 [details] [review] Fix the path to xcb_aux.h Remove RPATH with sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool `make check' fails Making check in image make[1]: Entering directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' make test_swap make[2]: Entering directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' gcc -DPACKAGE_NAME=\"xcb-util\" -DPACKAGE_TARNAME=\"xcb-util\" -DPACKAGE_VERSION=\"0.3.2\" -DPACKAGE_STRING=\"xcb-util\ 0.3.2\" -DPACKAGE_BUGREPORT=\"xcb@lists.freedesktop.org\" -DPACKAGE=\"xcb-util\" -DVERSION=\"0.3.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_VASPRINTF=1 -I. -I../aux -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT test_swap-test_swap.o -MD -MP -MF .deps/test_swap-test_swap.Tpo -c -o test_swap-test_swap.o `test -f 'test_swap.c' || echo './'`test_swap.c mv -f .deps/test_swap-test_swap.Tpo .deps/test_swap-test_swap.Po /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o test_swap test_swap-test_swap.o -lxcb ../aux/libxcb-aux.la libxcb-image.la DIE_RPATH_DIE="/usr/lib64:$DIE_RPATH_DIE" gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/test_swap test_swap-test_swap.o -lxcb ../aux/.libs/libxcb-aux.so ./.libs/libxcb-image.so creating test_swap make[2]: Leaving directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' make check-TESTS make[2]: Entering directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' /root/rpmbuild/BUILD/xcb-util-0.3.2/image/.libs/lt-test_swap: error while loading shared libraries: libxcb-aux.so.0: cannot open shared object file: No such file or directory FAIL: test_swap ========================================== 1 of 1 tests failed Please report to xcb@lists.freedesktop.org ========================================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/root/rpmbuild/BUILD/xcb-util-0.3.2/image' make: *** [check-recursive] Error 1 Attached patch fixes the problem.
Comment on attachment 21276 [details] [review] Fix the path to xcb_aux.h No, it is not. My fault.
Sure it fails, when I do the RPATH mangling, I kill the PATH to newly build .so's and replace them with the one's in /usr/lib64 (where they are not, xcb-util is not installed yet).
As near as I can tell, this use of -rpath is the result of stuff automatically incorporated into aclocal.m4 by aclocal rather than the result of any explicit action by the XCB config. If my diagnosis is correct, then fixing autotools to not do that on platforms that don't want it would be a better plan than having each autotools user work around this usage individually. I'm marking it NOTOURBUG for now, but I'd be willing to be persuaded otherwise if I'm just confused here.
Frankly, AFAIK, that resolution is incorrect. The correct one is NOTABUG. Why ? Well, lets think for a moment what exactly rpath does... If rpath in the library is set to (NULL), that library will only be useful for a program, if it's either in one of the dirs of ld.so.conf or somewhere within LD_LIBRARY_PATH. As during 'make check' library is still not installed, it works only because rpath is set to the dir, were the lib was built, only during install this value is changed to the system path (and IIRC, libtool skips adding a few standard rpaths, like i.e. /usr/lib).
Thanks much for the clarifying comment, galtgendo! I think it's marginal whether this use of -rpath is a bug; it seems to me that there's some chance of a poorly-chosen rpath leaking into the installed binary, and some folks seem quite concerned by the security implications of that. I'm going to leave it NOTOURBUG for now, as that subsumes NOTABUG and I don't want to think about it any more. :-) However, your point is well-taken---under ordinary circumstances it's likely there's no security issue here.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.