[PATCH]: Fix GLX crashes on RISC cpus.

[Paulo Cesar Pereira de Andrade]

Alan Coopersmith wrote:
> pcpa at mandriva.com.br wrote:
>> If you check the
>> existing video modules, there are other problems, mainly due to not
>> compiling with more verbose gcc warnings neither using any tools to 
>> check
>> for things like unresolved symbols (I am using a perl script that parses
>> the output of "objdmup -t -T -w --demangle" and cross references symbols
>> and "simulates" loading of shared libraries), i.e. things like 
>> modules with
>> missing symbols (function calls) that are actually macros, but the 
>> proper
>> headers were not included, C files declaring "extern" functions that 
>> don't
>> exist, etc.
>
> I haven't had a chance to update our Solaris builds to 1.4 yet, but we're
> building 1.3 and all the drivers we ship (most, but not all, of the video
> & input drivers) with -z defs using a mapfile for the Xorg exported 
> symbols
> generated at build time with nm.   I did find a couple of unresolvable
> symbols that way, but they were all fixed before 1.4.
  Yes, the problems are more like a "lack of human resources", or some kind
of X Org "janitors" team, that would work on making sure old drivers still
work (usually ISA only cards), that lib*fb*so that isn't libfb.so still
is usable, and people watching over the commits to not "easily" allow
breaking API if an alternate/compat method is doable, etc.

  I don't know what video drivers are available for Solaris (well, for x86
should be the same as Linux :-), but unless you added local patches, 
anything
other than things like ati/nv/intel/vesa have high chances of being broken.
Almost all lib*fb*.so other than libfb.so are broken in 1.3. In 1.4 most
missing symbols were fixes, and I believe only libxf8_32bpp.so has 
unresolved
symbols, I don't remember all the details, but I think some "magic" must be
done to another file, like what is done with cfbgc.c - cfbgc8.c - cfbgc32.c.
  There is also the problem of symbol clashes, but if I recall corectly, the
only case it happens outside Xserver<->libraries is the modes directory,
if for some reason a driver that has a copy of this code is compiled using
it, while the server compiles with its own version, but that is another
history and/or usually a "fault" of whoever compiled a module before the
X Server (better to have a symbol defined 2 or more times than never 
defined) :-)

Paulo