Bug 97840

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.

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 :)

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.

Here is Brian's response from mesa-dev mailing list:

Date: Tue, 01 Jul 2003 09:21:51 -0600
From: Brian Paul <brian>
To: Mike A. Harris <mharris>
Cc: mesa3d-dev.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

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.

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.

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.

Fixed by XFree86-4.3.0-libGL-multitexture-defines.patch in XFree86 4.3.0-22
in RAWHIDE.  Closing bug.

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.

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."
 

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>
To: Mike A. Harris <mharris>
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

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.

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.