libGL and libGLU buildtime dependancy virtualization

Luciano Miguel Ferreira Rocha strange at nsk.no-ip.org
Mon Jul 5 09:12:46 UTC 2004


On Mon, Jul 05, 2004 at 03:40:43AM -0400, Mike A. Harris wrote:
> There are various libGL and libGLU implementations floating
> around nowadays and generally speaking, most applications that
> link to either library do not require any specific
> implementation.
> 
> In Red Hat packaging, libGL and libGLU have both moved from 
> package to package and subpackage to subpackage over time.  
> Applications which link to these libraries do not and should not 
> hard code a dependancy on the binary rpm package that provides 
> either of these runtime libraries, as rpm's autoreqprov script 
> will set the dependancy on the actual library rather than the 
> package it is included in.  This has the benefit that as long as 
> any implementation of the library is installed on the system via 
> rpm, at the same filesystem location as what an application was 
> linked to, rpm package installation will be happy, even if you 
> have a different libGL installed than was used to link the 
> application.
> 
> In plain english, building fooGL on a stock Red Hat OS 
> installation with all packages installed, will cause fooGL to be 
> linked to the Mesa libGL which is included with the X 
> implementation included in the OS (either XFree86 or X.Org, 
> depending on OS release).  RPM will automatically add a runtime 
> dependancy on:
> 
> 	libGL.so.1
> 
> or more accurately on "libGL.so.<version>" that the app was 
> linked against.  As long as you have the Red Hat package that 
> includes libGL.so.1 installed, the dependancy is met at runtime, 
> even if we move libGL to a different package at some point.  
> (It's moved from Mesa to XFree86-libs to xorg-x11-libs over the 
> years).  Regardless of what package provides this library, all 
> apps relying on rpm dependancy checking should be happy.
> 
> 
> Problem:
> 
> Buildtime dependancies.  In order for your libGL and libGLU
> packages to have proper BuildRequires lines that specify all
> required build/devel dependancies, you need to specify what
> packages provide the needed headers and .so symlinks.  This
> causes a problem because the package that includes the libGL and
> libGLU headers has changed over the years, and it is possible it
> will continue to change in the future from time to time.
> 
> If you want to make an rpm package that has all of it's
> BuildRequires specified correctly, and links to libGL, and is
> buildable on all Red Hat Linux 7.x releases, Red Hat Enterprise
> Linux, and Fedora Core 2, you'll have a slight problem, because
> the libGL and libGLU headers are in 3 different binary rpms
> across that range of OS releases.  Currently, there are 2 ways
> people can resolve this in an OS neutral fashion:
> 
> 1) Specify a build dependancy on the actual header file:
>    ie:  BuildRequires: /usr/include/GL/gl.h
> 
> or
> 
> 2) Use rpm macros to select one of 3 different build 
>    dependancies, based upon which OS target the package is being 
>    built for:
> 
> %if %{build_mesaGL}
> BuildRequires: Mesa-devel >= 3.4.2
> %endif
> %if %{build_XFree86_mesaGL}
> BuildRequires: XFree86-devel >= 4.2.0
> %endif
> %if %{build_xorg_x11_mesaGL}
> BuildRequires: xorg-x11-devel >= 6.7.0
> %endif
> 
> 
> >From the two above, #1 is obviously simpler and probably the most 
> used.  #1 will also work with any rpm packaged libGL, and not 
> just the ones that Red Hat has shipped.
> 
> One problem with either approach however, is that it does not 
> specify a particular libGL API version, and there is no easy way 
> to do so.
> 
> Another problem, is that some rpm packagers will put a 
> BuildRequires: XFree86-devel to pick up the libGL headers, but 
> that will make their rpm package not rebuildable on X.Org, or 
> vice versa.
> 
> What I am considering doing, to try to solve these problems, is 
> to start including virtual provides for libGL-devel from now on 
> to all rpm subpackages which provide the libGL development 
> headers and symlinks.
> 
> Example for X.Org X11 would be adding the following to our 
> xorg-x11-devel subpackage dependancy information:
> 
> %define libGL_version 1.2
> ...
> Provides: libGL-devel = %{libGL_version}
> 
> The same would be done for libGLU, and possibly other libraries.  
> RPM packagers could then start using the virtual BuildRequires to
> pick up the correct libGL headers, etc.:
> 
> BuildRequires: libGL-devel >= 1.2
> 
> It would likely take a couple of OS releases before these changes
> would catch on, but it's a longterm future-proofing that will
> IMHO help keep build dependancies libGL agnostic and X11
> implementation agnostic (and agnostic as to wether X11 is
> installed at all).
> 
> Before I add these changes to our X.Org packaging for FC3 
> however, I wanted to hear some constructive feedback and 
> other ideas from others.  If I go ahead with the changes, I will 
> eventually add similar changes to future updates of XFree86 and 
> X.Org X11 for previous OS releases that we still support, so that 
> people can start using the virtual provides sooner than later.
> 
> Your feedback is appreciated.
> 

Is there any implementation neutral 'Provides:'? Even xorg and XFree86 don't
provide a X11-devel. I even think it was discussed when the change to
xorg-x11 occurred.

The current OpenGL implementation used in Fedora is the Mesa one, and
xorg-x11-devel does provide it:
$ rpm -q --provides xorg-x11-devel
xpm-devel
Mesa-devel
XFree86-devel = 4.4.0
xorg-x11-devel = 6.7.0-4

Is there any reason to make libGL a special case? The current situation
could be improved by specifying the Mesa version that is provided, that
should be enough for the GL version.

Regards,
Luciano Rocha





More information about the devel mailing list