Bug 97840 - bad OpenGL header (gl.h) included in XFree86-devel
bad OpenGL header (gl.h) included in XFree86-devel
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
http://bugs.winehq.com/show_bug.cgi?i...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-22 23:25 EDT by Dan Berger
Modified: 2007-04-18 12:54 EDT (History)
1 user (show)

See Also:
Fixed In Version: 4.3.0-22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-10 17:28:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Berger 2003-06-22 23:25:04 EDT
Description of problem:
The gl.h header included in XFree86-devel is defective - it incorrectly
surrounds OpenGL multitexturing related definitions with an ifdef.  This causes
OpenGL apps compiled against this header which use multitexturing to fail.

Version-Release number of selected component (if applicable):
XFree86-devel-4.3.0-2

How reproducible:
Always

Steps to Reproduce:
1. Build wine with opengl enabled
2. run an application (like Half-Life) that uses multitexturing
3. 
    
Actual results:

See the attachments in the wine bugzilla related to bug 1396


Expected results:


Additional info:

A working patch against the header file is included in the wine bug report at
http://bugs.winehq.com/show_bug.cgi?id=1396
Comment 1 Mike A. Harris 2003-06-30 22:57:09 EDT
Someone from the Mesa project will have to confirm and approve this fix first,
but I'll be glad to provide it after it's approved.  Has someone contacted them
already, or shall I go ahead?

Thanks.
Comment 2 Dan Berger 2003-06-30 23:47:01 EDT
please feel free to contact the Mesa folks if that's the appropriate party.  I
wasn't sure who the appropriate party was (since the mesa headers are included
in DRI which is included in XFree), which is part of the reason I punted to the
distribution :)
Comment 3 Mike A. Harris 2003-07-01 03:08:46 EDT
In general, it is best to go to the authors of a piece of software.  In this
case, the OpenGL interface is provided by Mesa.  Doesn't matter much that
Mesa is included in XFree86, it is Mesa itself which is where the code comes
from.

I'll email the devel list to poll for comments about this issue.

Thanks.
Comment 4 Mike A. Harris 2003-07-01 17:47:46 EDT
Here is Brian's response from mesa-dev mailing list:

Date: Tue, 01 Jul 2003 09:21:51 -0600
From: Brian Paul <brian@tungstengraphics.com>
To: Mike A. Harris <mharris@redhat.com>
Cc: mesa3d-dev@lists.sourceforge.net
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: [Mesa3d-dev] User reported bug in GL header files in 4.3.0

Mike A. Harris wrote:
> A user just reported the following bug to me in bugzilla:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97840
>
> I'm not really willing to make bug fixes to Mesa in XFree86
> however unless they're approved by the Mesa development team, or
> really obvious fixes.

According to the bugzilla report, this was fixed in Mesa 4.1 and
later.  The next time there's a DRI->XFree86 merge this'll be resolved.


> Could someone look at this and comment on the issue, and state
> why it is or isn't a bug?

I guess I still don't see what the real issue is.  There's no harm in
defining the GL_ARB_multitexture tokens, prototypes and function
pointers in gl.h where they were (instead of in glext.h).

I also don't understand how this compile time issue with wine effects
a game at runtime.

-Brian
Comment 5 Mike A. Harris 2003-07-01 17:55:21 EDT
The patch included in the wine bug report is cut and pasted however, which
means it likely wont apply at all (they rarely do).  It's also against the
installed file not the source code.

I'll have to muck with this to regenerate a patch directly against 4.3.0 sources
for our next OS release, unless someone beats me to it and attaches a unified
diff to this report as a file attachment.  The latter will likely get it
included sooner though.  ;o)

Assuming it causes no regressions, it'll be included in future RHL 9 erratum
as well.

Thanks.
Comment 6 Dan Berger 2003-07-01 18:48:42 EDT
It's literally a one-line change - just move the 

#if defined(GL_GLEXT_LEGACY) 

from it's current position down to immediately after 

#endif /* GL_ARB_multitexture */

I don't have the xfree source RPMs handy or I'd toss you a patch - sorry.

I've also confirmed that this bug only exists in Mesa 4.0.4 - 4.0.3 is correct,
and 4.1 is correct - so I'm pretty confident that this is the right thing to do.
Comment 7 Mike A. Harris 2003-07-01 19:15:36 EDT
I agree, and that's what I'll do.

It's being tracked for our next OS release, and will be fixed in a future
rawhide XFree86 update.  I'll close this bug as RAWHIDE when it is integrated.
Comment 8 Mike A. Harris 2003-08-24 04:17:51 EDT
Fixed by XFree86-4.3.0-libGL-multitexture-defines.patch in XFree86 4.3.0-22
in RAWHIDE.  Closing bug.
Comment 9 Dams 2003-08-24 20:59:13 EDT
The header is not defective. I repeat : the header is *not* defective.

Please consider the answer on mandrake bugzilla at
http://qa.mandrakesoft.com/show_bug.cgi?id=4880 and re-open the bug (to close it
as *notabug*). 

I've tried to build some small opengl game and the build did not fail. You just
have to sed s/glActiveTextureARB/glActiveTexture/g (same for others ARB
functions) in the source and all is fine.
Comment 10 Dan Berger 2003-08-24 21:38:14 EDT
If this is the case (and I'm not saying it isn't - as I don't know), someone
needs to alert the XFree and Mesa folks - as they've "fixed" something that
wasn't broken in current releases.  The release of Mesa that was integrated with
XFree is the only release that behaves in the way reported in this bug. 
Previous and future versions are "fixed."
 
Comment 11 Mike A. Harris 2003-08-25 20:47:47 EDT
The Mesa folks are well aware of this issue, and have discussed it in the
past.  I just re-contacted Brian Paul, the Mesa project founder and primary
developer, and asked him for clarification on this issue.  Here is his
response to my email, which I consider authoritative:


Date: Mon, 25 Aug 2003 08:25:09 -0600
From: Brian Paul <brian@tungstengraphics.com>
To: Mike A. Harris <mharris@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Old Mesa bug question..

Mike A. Harris wrote:
> I hate to bother you about this issue again, however numerous
> people have complained about a bug in our bugzilla that was open
> which I asked for your advice on in the past.  I don't have the
> original emails handy so I don't remember our original
> conversation.  Here is the bug in question:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97840
>
> After rereading the report, and the linked to Mandrake report,
> and some of your commentary, I'm lead to believe that this issue
> is not a bug afterall.  Rather than ping ponging a patch on and
> off between 2 factions of people who disagree with each other in
> the report, I'm wondering if you could have a quick peek, and
> give an authoritative position on this issue and wether or not
> the patch should be applied.
>
> My inclination at this point, is to remove that patch because
> upstream does not have the patch in XFree86 CVS.
>
> Any recommendation?

I think the gl.h file in Mesa CVS (and DRI CVS) is correct as-is.
The current gl.h in XFree86 DRI, however, is not up to date.

A DRI -> XFree86 merge is overdue.

I don't know when the next XFree86 release is planned.

-Brian
Comment 12 Mike A. Harris 2003-08-25 20:51:21 EDT
I will be reviewing the current Mesa and DRI CVS, and will make whatever
changes (if any) are necessary to bring our Mesa in line with Brian's
recommendation above.

If anyone disputes this resolution, please move it to the Mesa-dev mailing
list as I'm not going to get caught in the middle of dissenting opinions.

If people disagree with Brian, then you'll need to convince him first to
change anything before I will consider changing it in our sources, as I
consider Brian as authoritative on such matters.

Reopening for now until I can examine the CVS repositories and finalize this.
Comment 13 Mike A. Harris 2003-09-10 17:28:03 EDT
I've patched gl.h with the changes above, and there should not be any problem
with this patch being applied.  I've decided to keep the patch, as without
it, a steady stream of bug reports comes in claiming Red Hat XFree86 has a
broken libGL.

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