| Summary: | After RPATH removal `make check' fails | ||
|---|---|---|---|
| Product: | XCB | Reporter: | Michal Nowak <mnowak> |
| Component: | Utils | Assignee: | xcb mailing list dummy <xcb> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Fix the path to xcb_aux.h | ||
|
Description
Michal Nowak
2008-12-18 06:10:31 UTC
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.