Easier to find reference (the URL field seems obscure <grin>):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132160

Me and Kristian discussed this in IRC today for some time, and here are some
thoughts about the issue.  Initially I misread the issue of being Motif
dragging around libGLw headers, but it's the other way around.  The problem
with dragging another library's headers around, is that you either have to
synchronize with that library over time, or you fall out of touch and changes
in the library may end up with incompatible interfaces in your local copy
that do not match the new library.  For this alone, I think it is very very
bad to drag around openmotif headers just for libGLw's personal usage.  I think
that they should be removed from X.Org completely, and if you enable the
compilation of libGLw, you _must_ have a motif implemenation installed in
order to link to.  This is the only sensible way to guarantee you're using
compatible motif headers.

That's just the first problem though.

The real problem here, is that Motif changed the interface by adding new
symbols without bumping the library version.  Since libGLw carries around
motif headers currently, it will be tied to a specific motif version and
assume no incompatible binary changes are made (which *should* be a safe
assumption, but can't be relied upon really).  So the way I currently see
this, is that updating the libGLw copies of motif headers and rebuilding
libGLw with them, will just produce a new libGLw with the same .so version,
linked to a newer version of Motif which is binary incompatible.  Apps linked
to the older libGLw and older OpenMotif will break if we update the libGLw
to use new motif headers.  Keeping the old headers means that current
apps work, but building apps against current Motif 2.2 or later will fail
due to the MOtif changes.

It appears to be a very ugly problem IMHO.  It isn't clear what is the best
solution which retains both source and binary compat of libGLw, openmotif, and
apps that use either.

http://cvs.motifzone.net/cgi-bin/cvsweb.cgi/openmotif/lib/Xm/PrimitiveP.h?cvsroot=openmotif

Anyone care to comment on this?

(In reply to comment #2)
> Anyone care to comment on this?

The current version in the tree seems to work with the normal version of Motif
(tested on Solaris) so the problem is likely specific to OpenMotif... best
solution may be to ask the OpenMotif guys what we should do here...

This is an OpenMotif bug.  They have an incompatible libGLw header in
their own source tree IIRC.

Setting status to "NOTOURBUG"

Created attachment 3101 [details] [review]
Patch to update libGLw's Motif headers

I'm not sure why this was closed, because libGLw definitely has an out of date
copy of OpenMotif's PrimitiveP.h, not the other way around.  This is a major
showstopper for many of our apps.  I've tested this patch with OpenMotif 2.1 and
2.2.  Under 2.1 the tool tips member just adds extra padding but no crashes
occur.  That is, one build is in fact binary compatibile with both 2.1 and 2.2,
and libGLw doesn't actually link to libXm.  Yes, the duplication of headers is
ugly, but can we update libGLw so it at least works?

Please just remove this header completely.  Make it a necessity that
openmotif be installed in order to compile libGLw.  This is insane to
patch like this, as it is an ongoing maintenance hell.

libGLw is at any rate a Mesa component, not an Xorg component.  shifting
appropriately...

The GLw sources in Mesa do not include PrimitiveP.h, XM.h, etc.  Here's a
directory listing:
$ ls Mesa/src/glw/
CVS/        GLwDrawA.h   GLwMDrawA.c  GLwMDrawAP.h  README
GLwDrawA.c  GLwDrawAP.h  GLwMDrawA.h  Makefile

Furthermore, I don't see a libGLw in x.org's git tree.

This bug report may be obsolete.  Can anyone confirm?