I am making fresh install. Installing xfree-4.3.0-r2 I saw that /usr/X11R6/lib/modules/extensions directory is not made. This directory is important for storing libglx and hence, opengl-update nvidia fails. The ebuild for xfree-4.3.0-r1 works fine. This error is reproduced each time I upgrade or even make fresh xfree install Also, xft is not build with r2 ebuild, but get build as dependency on r1 ebuild Reproducible: Always Steps to Reproduce: 1.Either upgrade or make fresh install 2. 3. Actual Results: When the xfree-4.3.0-r2 build is complete, it runs fine with xfree's nv driver, but it fails to run with nvidia drivers. Expected Results: Should run with nvidia drivers and build xft dependency as in r1 ebuild
Created attachment 14268 [details] this is the XF86Config file I run
Created attachment 14269 [details] this is the XF86Config file I run
Created attachment 14270 [details] this is xfree86.0.log
Same on my box, that appears when I tend to recompile Xfree. The file /usr/lib/opengl/xfree/extensions are not there. I'll try to recompile X
I tried the last Xfree ebuild ( 4.3.99.8 ) and it solved the problem. But I don't know if it won't create new bugs, so it's better to see if there's another way to fix it.
I tried again on fresh machine and the error remains as it is. I have not tried the 4.3.99.8 build. Although -r3 ebuild has same problem as of -r2. Some ppl do not seem to have this problem. I did check partition for errors. Nothing wrong BTW my card is NVIDIA VANTA
Found what was causing this error. I was using debug flag as default and the ebuild shows that LoadableServer is made off. Thats why nvidia modules cannot be loaded. I dunno why this is has been added suddenly. The code in the ebuild thats it >> if [ -n "`use debug`" ] then echo "#define XFree86Devel YES" >> config/cf/host.def echo "#define DoLoadableServer NO" >>config/cf/host.def >> To make this ebuild work with nvidia-drivers/ nvidia-glx use: USE="-debug" emerge xfree
A static build should not load external libs, so perhaps nvidia-glx should do some sort of check to see if xfree was built statically. Az, what do you think?
This isn't a blocker in my classification. BTW, it _should_ be possible to do this once portage 2.0.50 comes out with support for USE flags in packages.
*** Bug 32516 has been marked as a duplicate of this bug. ***
This bug has yet to be resolved, and needs too. I had problems with building xfree and xorg with hardened gcc. The only solution was to build a static xfree/xorg. This makes it impossible to use the nvidia modules, which are needed for opengl support. Please oh please someone fix this bug, or the one where building xfree/xorg with hardened gcc produces a build error with the bitmodmap.a library. We users just want to use X.
Both bugs have "fixes." There is no way I'm aware of to build nvidia's binary driver into a static X server. There might be some strange way to relink things, but I'm certainly not aware of it. Your "fix" here is "Use static, OR use nvidia's binary drivers. Your choice." If you or anyone else comes up with a better way to solve this, please, feel free to post it. cyfred or tseng, you know more about linking etc?
You cant have your cake and it too in this case. You are building a static X server to *build* properly with the hardened compiler. There are actually two issues here, so I'll hit you with the history: We patched Xfree 4.3.0 to build properly with hardened gcc awhile back. This was well and good. Xorg came along, and our fixes dont transfer over cleanly. Port the patches, you say? So we'll get into the larger issue. If you are using hardened gcc, you are probably doing so to best take advantage of PaX via PIE binaries and the complimentary SSP. If you arent, you are wasting your and my time, but the issue remains. Xfree/Xorg on most systems are "modular", as they load parts of the code at run time vs being built in. This sounds like an ok idea, the kernel does it, right? The problem is the way this happens. In a normal UNIX-like application, when the main application wants to use a shared library, it is linked at compile time to that library dynamically (vs static). At runtime, this shared object is loaded based on how it was linked. Xfree doesnt do it this way.. it actually executes its own code at runtime to load dependent modules. This "Metrolink" loader executes off the heap, which PaX kills. Enter the dlloader. The dlloader is an alternative module loader in xfree/xorg that uses dlopen to resolve dependencies based on link-time info. Since the modules currently arent linked properly, it falls on its face with dozens of unresolved symbols. In xorg, its possible to resolve these by changing the way the OSS drivers are built. You have two problems left. First, and most obvious, the nvidia driver isnt open source, so you dont have many clues trying to fix it from the outside. Secondly, and more importantly, the nvidia driver itself performs runtime code generation, making the effort to make it work in an NX-protected X server competely futile. Here ends the parabol of why nvidia-kernel and Hardened Gentoo cannot currently. and will not futurely, exist on this course.
I consider this bug to be invalid, because building something as "static" implies that it cannot dynamically load modules, like the closed source nvidia drivers.
*** Bug 74430 has been marked as a duplicate of this bug. ***
