From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041228 Firefox/1.0 Fedora/1.0-8 Description of problem: xorg-x11-devel installs the symlink: /usr/X11R6/lib/libGL.so -> libGL.so.1.2 which is dead on my system, because libGL.so.1.2, part of xorg-x11-Mesa-libGL is not installed. Instead libGL.so.1 (required by xorg-x11) is provided by nvidia-glx (livna.org). /usr/lib/libGL.so links to /usr/X11R6/lib/libGL.so The result, for me, is that wine-cvs fails to detect opengl support, gets build without it, and warcraft/frozen throne don't work - not cool. Since xorg-x11 does not require xorg-x11-Mesa-libGL, or libGL.so.1.2, it would be nice if it didn't make assumptions about their existence. Version-Release number of selected component (if applicable): xorg-x11-devel-6.8.1.902-1 How reproducible: Always Steps to Reproduce: 1. See summary Additional info:
Shouldn't this stuff be split up like this: xorg-x11-Mesa-libGL (.so link, GL library) xorg-x11-Mesa-libGLU (.so link, GLU library) xorg-x11-Mesa-libGL-devel (all GL headers, .a ) xorg-x11-Mesa-libGLU-devel (all GLU headers, .a) That's what other packages seem to do. Currently no -devel packages exist, and the headers, as well as the .so links are in the xorg-x11-devel package, which causes the links to point to the wrong place, and also I have two sets of GL headers installed, one from xorg-x11-devel, and one from nvidia-glx-devel, which I should be using.
Or actually the .so links should go in -devel too, so I guess it seems to me that the .a, the .so, and the headers for libGL and libGLU should be split in their own development packages.
Are you using the drivers downloaded directly from Nvidia, or are you using the livna Nvidia rpm packages? The latter should "just work" and are highly recommended. In the future, X.Org will be modularizing, and we plan on breaking up the packaging somewhat of things to fit in better with the modularization. When this occurs, we will likely repackage Mesa more similarly to the way it was before when it was a standalone rpm package.
"Are you using the drivers downloaded directly from Nvidia, or are you using the livna Nvidia rpm packages? The latter should "just work" and are highly recommended." ... I am using nvidia-glx + nvidia-glx-devel + kernel module from nvidia's installer (patched for memory leak) + fake-provides that lies to nvidia-glx that I have the module package installed + custom X config, for optimal performance, and because the nvidia-glx startup script can't get it right (it looks for the module in the wrong place, because I didn't install it with the rpm). There is no way to properly install Nvidia drivers on Fedora Rawhide that I know of, because livna does not stay in sync. By the way, even with FC3 setup, and the correct RPMs the problem I am describing is still valid. If you install all the livna nvidia packages on FC3, and try to build stuff against libGL it will probably not work. /usr/lib/libGL.so points to a dead link when Mesa's not installed. "In the future, X.Org will be modularizing, " Right, but my point is that you've half-modularized Mesa already, and that's causing problems. It doesn't make sense to put the libGL in a separate package, and then keep the devel stuff with everything else. If I'm able to replace the Mesa GL library (which I can do), I should be able to replace the devel stuff as well.
In a perfect world, Mesa would be in it's own package, and it would have a -devel package as well. Ditto for libGLU. Initially, both of these were in the main -libs and -devel package, however a few ISVs requested that we separate these two libs out, so that they could be replaced easily by 3rd party drivers. We did that about 6 OS releases ago now, and for the most part, none of the hardware vendors took advantage of it. ;o( Mesa-devel tidbits ended up in the -devel package, as that's where all other X supplied libs development headers were at the time. It would have made some sense to have separate -devel packages for each of these libs, but at the time, there were no visible problems reported to us in bugzilla, nor could we envision any with keeping them in the -devel package. At the same time, we were trying to cut down on extraneous subpackages, as the distribution had started to divide things up into more and more subpackages, and it was felt that this should only be done to a point, and only when there were strong enough benefits to weigh against any disadvantages, etc. So, at the time the decision was made, there weren't any loud voices pointing out problems with the scenario. It's been about 6 OS releases since now, and only 2 or 3 people have even mentioned it. Having said that, a lot has changed since that point in time, and extra subpackages aren't as evil now as they were back then. If I were doing the same change today as back then, I'd have added extra -devel packages for libGL and libGLU. When we add -devel packages for libGL and libGLU, all of the apps that link to libGL in the distribution, Fedora Extras, and all 3rd party repositories, etc. will have to be possibly modified to add a new BuildRequires to ensure the libGL headers and .so (or for libGLU) are installed. There is likely to be a lot of broken rpm packaging out there that does not have "BuildRequires: libGL-devel" or similar in it, and so when we make this change, even though it is correct, a lot of things out there will break. When the X.Org modularization occurs, all libraries will be split out into their own rpms, and have their own -devel subpackages more or less. Since this will cause a similar problem for all X libraries, we have a migration path planned that will attempt to make this transition cleanly, and for all libs. When this happens, libGL and libGLU will benefit from the changes as well. The xorg-x11 packaging is shared between multiple OS releases, and we keep the packaging consistent between all releases that ship the same release of Xorg. A change of this nature is large in impact to developers, and so such a change will only occur in a new OS release, rather than as erratum for any existing release. Since X.Org X11 6.8.2 is what will most likely ship in Fedora Core 4, and it will be shared with RHEL4 and FC3 as well, this type of change is not feasible for FC4. Once upstream X.Org modularization is complete, we will have libGL and libGLU and all other X libraries in their own standardized packaging, and you will be able to do what you would like in an out of the box OS install. In the mean time, users using unsupported proprietary or other 3rd party libGL/libGLU replacements (in rpm format or not) will have to make some manual changes to their system to work around this issue. Setting status to "DEFERRED". Will re-review again when X.Org modular release is close to being released.
"When we add -devel packages for libGL and libGLU, all of the apps that link to libGL in the distribution, Fedora Extras, and all 3rd party repositories, etc. will have to be possibly modified to add a new BuildRequires to ensure the libGL headers and .so (or for libGLU) are installed. There is likely to be a lot of broken rpm packaging out there that does not have "BuildRequires: libGL-devel" or similar in it, and so when we make this change, even though it is correct, a lot of things out there will break." I don't understand. Those are _development_ packages. Why should anything link to the .so at all? This should break nothing at all. [root@cobra ~]# rpm -q --whatrequires libGL.so no package requires libGL.so [root@cobra ~]# rpm -q --whatrequires libGLU.so no package requires libGLU.so [root@cobra ~]# ... and there's about four things that currently require xorg-x11-devel. I have most of the distro installed on this machine here. [root@cobra ~]# rpm -q --whatrequires xorg-x11-devel openmotif-devel-2.2.3-8.1 Xaw3d-devel-1.5E-1 qt-devel-3.3.3-16 xorg-x11-deprecated-libs-devel-6.8.1.902-1 [root@cobra ~]# I'm not entirely sure of the reasons for one -devel package to require another. Headers come to mind, but I doubt there's a lot of issues with this. "The xorg-x11 packaging is shared between multiple OS releases, and we keep the packaging consistent between all releases that ship the same release of Xorg. A change of this nature is large in impact to developers," What large impact to developers? I still don't understand. Besides, I don't see how shuffling files between packages without changing their location can affect anything other than rpm dependency checking. This looks like a trivial, and easy to do change - I'm not sure what the big deal is. This is a bug, which is preventing building of GL apps on nvidia systems, and it should be fixed imho, otherwise the livna people might as well get rid of the nvidia-glx-devel package, since it doesn't work.
>I don't understand. Those are _development_ packages. Why should >anything link to the .so at all? This should break nothing at all. When _building_ a src.rpm, it specifies it's build dependancies as "BuildRequires". Right now, OpenGL using applications that are rpm packaged, in general are also X11 applications, not just OpenGL apps. They specify "BuildRequires: xorg-x11-devel" or "BuildRequires: XFree86-devel", and they end up getting both an X11 devel environment *and* libGL (and GLU) devel environment, so if they link to libGL/libGLU, it "just works". Moving the .so links into a library specific -devel subpackage would mean that all software currently expecting the X devel package to contain GL/GLU development headers and .so links, would no longer compile without installing the separate -devel package for each of these two libraries. The only way to fix the problem is to fix every src.rpm package out there which has software that links to libGL/libGLU, to have BuildRequires on a virtual provide we put into the library -devel packages. This is NOT a runtime installation problem, it is a compile time problem, so your above rpm queries do not show the problem I am describing. This change will occur when we make the transition to X.Org modular packaging, as I've indicated above. I think I've carefully articulated the reasons why above enough already, and I don't have any further comments to contribute to this thread, so please don't feel offended if I don't respond to further debate. Thanks in advance.
"I don't have any further comments to contribute to this thread," Hold on, I thought we were having a discussion here. I see the problem which you describe, and I want to help fix it. I disagree that the changes required have such magnitude. I just downloaded the entire distro (2.7 G or so) in SRPM, and here are all the packages that depend on xorg-x11-devel: alsa-utils-1.0.7-2.src.rpm anaconda-10.2.0.11-1.src.rpm cdicconf-0.2-9.src.rpm gimp-2.2.2-3.src.rpm gnome-mag-0.11.7-1.src.rpm gnuplot-4.0.0-6.src.rpm groff-1.18.1.1-5.src.rpm kinput2-v3.1-23.src.rpm libtabe-0.2.6-12.src.rpm linuxwacom-0.6.4-6.src.rpm MagicPoint-1.11b-2.src.rpm mozplugger-1.6.2-4.src.rpm openmotif21-2.1.30-13.1.src.rpm openmotif-2.2.3-8.1.src.rpm pango-1.8.0-1.src.rpm qt-3.3.3-16.src.rpm x3270-3.3.3.b1-1.src.rpm Xaw3d-1.5E-1.src.rpm xboard-4.2.7-7.src.rpm xosview-1.8.2-1.src.rpm xrestop-0.2-4.src.rpm xscreensaver-4.18-17.src.rpm 22 packages, and I bet most of them don't need openGL /GLU. I will look at them one by one, and see which ones require GL.
Actually that would solve half of the problem anyway. The other half is that the nvidia-glx-devel package installs its .so link and headers in nvidia subfolder, where nobody will look unless specifically developing for the nvidia GL lib (-L/usr/lib/nvidia -I/usr/include/nvidia). How can it be done so that the nvidia-glx .so link and headers are used when necessary, and Mesa when no nvidia stuff is installed? /usr/lib/ligGL.so is currently a link to the Mesa stuff (or rather a dead link, because Mesa is gone since it causes chaos when installed parallel to nvidia libGL) /usr/include/GL is a folder. Maybe the GL headers should be installed in /usr/X11R6/include/GL, and the linked to by /usr/include/GL. How about this scheme: xorg-x11-Mesa-libGL-devel would install in /usr/X11R6/libs and /usr/X11R6/include nvidia-glx-devel would install in /usr/lib/nvidia and /usr/include/nvidia Both would set the links /usr/lib/libGL.so and /usr/include/GL in their post-install script. Any ideas? I'm just trying to find some solution. I know you don't oficially support the livna nvidia stuff, but it just seems wrong that there's no proper way to do GL builds on a system with nvidia-glx installed without manually setting and resetting links every time X is updated.
Well on second thought that wouldn't work because all the GLU, GLw, and GLUT stuff goes in that folder as well.
So..the only srpms in the entire distro which explicitly require xorg-x11-devel, and actually use GL or GLU are qt and xscreensaver. I can check fedora.us and jpackage and livna if you want me to?
Targetting for FC5
This is resolved in our modular X.Org X11R7 packaging now. The "mesa" src.rpm holds libGL, libGLU, and libGLw. Each library is put into it's own individual subpackage, and each library has it's own -devel subpackage. This allows any library to individually be replaced by 3rd party replacements as desired (although we don't support any 3rd party bits, but that goes without saying I suppose). This should allow Nvidia/ATI/etc. users to be able to mix and match however desired. I'm closing this as "NEXTRELEASE", as the work to implement this is currently "done" internally, however it is not publically available in Fedora devel yet. It will end up visible once we integrate it into the tree.