Description of problem: Symbol __stack_chk_fail from module ...(see attached file) is unresolved! Version-Release number of selected component (if applicable): [11:19 PM][awjb@arcturus ~]$ rpm -q xorg-x11 xorg-x11-6.8.2-52 How reproducible: always Steps to Reproduce: 1. startx
Created attachment 119278 [details] stderr output of startx
This is caused by gcc's stack-protector. It appears there is no "simple" solution to work around this problem and keep stack-protector support in the monolithic builds without more effort than it's worth to spend. As such, I'm disabling stack-protector for monolithic builds. Once modular X hits the tree, everything should build ok with stack protector presumeably except the X server, unless the problem has been resolved upstream by then. We'll keep it disabled in the X server at least until we have a proper solution that is also acceptable to upstream X.Org, as we definitely want to avoid a Red Hat specific solution that causes inter-distribution binary incompatibility of X server modules, as that would cause hardware vendors to build modules for each distribution individually, which would be 'bad' IMHO.
Are you using FC4 with random bits and pieces of Fedora devel? Curious because another person using devel says they don't see this error. I'm thinking the problem might only occur on mixed systems, although it is a bigger problem than just the failure to solve. Ultimately we do want stack-protector to be used. ;)
Actually its a devel with devel and fc4 repos enabled so if an fc4 version is > fc5 there probably is some fc4 stuff in there... actually I probably should track these packages down sometime ^^ Hope that helps. If you want an rpm -qa let me know...
Should be fixed in 6.8.2-54, by disabling stack-protector completely. When we put Xorg modular in rawhide, stack-protector will be automatically re-enabled for everything except the Xorg X server, unless we come up with a safe/sane way of doing so by then, as it'd be nice to have the additional protection. It'd cut down the seriousness of X server buffer overflows for certain. Thanks again for the report.