This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 145287 - xorg-x11-devel installs dead symlinks: libGL.so
xorg-x11-devel installs dead symlinks: libGL.so
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2005-01-16 20:15 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 18:39:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-01-16 20:15:28 EST
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:
Comment 1 Ivan Gyurdiev 2005-01-17 00:53:42 EST
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.
Comment 2 Ivan Gyurdiev 2005-01-17 02:02:26 EST
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.

Comment 3 Mike A. Harris 2005-01-17 07:02:05 EST
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.
Comment 4 Ivan Gyurdiev 2005-01-17 07:48:08 EST
"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.

Comment 5 Mike A. Harris 2005-01-17 11:36:15 EST
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.
Comment 6 Ivan Gyurdiev 2005-01-17 14:41:28 EST
"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.




Comment 7 Mike A. Harris 2005-01-18 01:48:55 EST
>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.
Comment 8 Ivan Gyurdiev 2005-01-18 05:06:32 EST
"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.
Comment 9 Ivan Gyurdiev 2005-01-18 06:26:33 EST
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.
Comment 10 Ivan Gyurdiev 2005-01-18 07:15:41 EST
Well on second thought that wouldn't work because
all the GLU, GLw, and GLUT stuff goes in that folder as well.

Comment 11 Ivan Gyurdiev 2005-01-18 23:21:47 EST
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?

Comment 13 Mike A. Harris 2005-04-20 11:18:48 EDT
Targetting for FC5
Comment 14 Mike A. Harris 2005-09-28 18:39:29 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.