Bug 114251 - couple of compile time problems
couple of compile time problems
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Glide3 (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alan Cox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-25 08:43 EST by d.binderman
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-15 12:13:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch against the Glide tree resulting from doing a rpmbuild -bp on the latest srpm, fixing all the compile errors and a few bugs (24.03 KB, patch)
2004-09-03 14:14 EDT, Hans de Goede
no flags Details | Diff
Improved patch (25.55 KB, patch)
2004-09-04 05:52 EDT, Hans de Goede
no flags Details | Diff
spec filing using my patch and with other improvements (10.87 KB, text/plain)
2004-09-04 05:58 EDT, Hans de Goede
no flags Details
ia64 patch with conflicting parts removed (127.32 KB, patch)
2004-09-04 06:00 EDT, Hans de Goede
no flags Details | Diff
asm patch (966 bytes, patch)
2004-09-04 06:02 EDT, Hans de Goede
no flags Details | Diff
slightly improved improved patch (25.72 KB, patch)
2004-09-07 07:51 EDT, Hans de Goede
no flags Details | Diff

  None (edit)
Description d.binderman 2004-01-25 08:43:59 EST
Description of problem:

I just tried to compile package Glide3-20010520-25, from Redhat
Fedora Core 1.

The compiler said

1.

../../../../swlibs/texus2/lib/nccnnet.c:414: warning: conversion lacks
type at end of format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: conversion lacks
type at end of format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: unknown
conversion type character `)' in format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: conversion lacks
type at end of format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: conversion lacks
type at end of format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: unknown
conversion type character `)' in format
../../../../swlibs/texus2/lib/nccnnet.c:414: warning: too many
arguments for format

The source code is

        printf("eMax=(%3l%3l%3l)...eAvg=(%3l%3l%3l)\n",
               errG, errR, errB,
               totG/ncolors, totR/ncolors, totB/ncolors
               );

%3l is only part of a specifier. Suggest use %3ld. 

Suggest also, to ensure that this bug cannot occur again, compile with
flag -Wformat or -Wall.

2.

The compiler also said

../../../../h5/glide3/src/g3df.c:479: warning: operation on `tempStr'
may be undefined

The source code is

   while(*tempStr != '\0') *tempStr++ = toupper(*tempStr);

Clearly broken code. Suggest

   while(*tempStr != '\0') 
   {
		*tempStr = toupper(*tempStr);
		++tempStr;
   }


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mike A. Harris 2004-01-26 05:12:15 EST
Yeah, Glide3's source code is very complex and sloppy.  It does
not compile under Fedora Core 1, RHEL 3, or even Red Hat Linux 9
anymore I don't believe.  Our existing RPM is inherited from Red Hat
Linux 8.0 if I recall correctly.  It also doesn't like new GNU
autotools.

Since Glide3 was more or less totally abandoned upstream when 3Dfx
went out of business, and hadn't been maintained upstream for over
2 years, our package has more or less been unchanged for all of this
time as well.

My plan has been to keep it in the distribution for as long as it
continues to compile, however it no longer compiles cleanly as you've
discovered.  ;o)  There are other problems in addition to the one
you've reported also.

On the other side of things, about 8-9 months ago 2 or 3 developers
joined the Glide project and have been working on it ever since
more or less on sourceforge.  They've gotten it to the point where
it no longer requires 2 separate Glide3 libraries, but can support
all hardware from a single library now.  They've fixed various other
issues as well.  I've considered updating to this new Glide3 for
a while, however for code which has been unmaintained upstream, and
unmodified for a couple of years now, Glide3 gets very very few
bug reports nowadays so I've been hesitant to upgrade it to the
newer codebase for a while, in order to see how actively the new
developers maintain it.

This leaves me with 5 options I can think of:

1) Drop Glide3 and no longer support it in future OS releases

I'd prefer not to do this, as I like to keep hardware support for
as much hardware as possible, for as long as possible.  People
naturally do not like their hardware support disappearing when they
upgrade their OS, no matter how old the hardware is.  Balance needs
to be found however.


2) Dig into Glide3 bugs, compile problems, etc. myself and effectively
   become an upstream maintainer.

I have no interest in becoming an upstream maintainer for Glide3,
as it is dead-end code, and disinteresting to me personally.  I
consider it legacy hardware support, and when legacy hardware is
not actively maintained upstream and has problems, we generally
discontinue to provide drivers unless there is compelling business
reasons for us to internally maintain the support ourselves.  For
3Dfx hardware, that isn't the case.  ;o)


3) Leave Glide3 as is in the distro, continuing to inherit the binary
   build from Red Hat Linux 8.0 era.

This has been my current approach, and I've done this more or less
because nobody has complained about it, and there haven't been
run-time bug reports for ages.  It seemed the most sensible and
least use of developer resources to do this, as it still provides
hardware support for 3Dfx hardware without a lot of developer time.

4) Include user submitted patches that fix problems a given user
   has with Glide3, thus keeping it in the distro for user
   convenience without having to waste developer resources
   maintaining the largely unmaintainable (IMHO) codebase.

This is a reasonable choice, but of course depends on the volume
of problem reports (currently low), and wether or not the bug
submitter can fix the problem and supply patches.  Due to the
legacy of the code, I'm not sure we'd get many patches.  ;o)


5) Upgrade our Glide3 package to the new Glide3 development code
   done by Daniel Borca and colleagues on sourceforge.

This option seems like it might be the best approach for me to
go with for Fedora Core 2, however I will need to evaluate the
new Glide stuff first, and test it out on at least one of each
3Dfx hardware generation.

So I think that is what I'll plan on doing for Fedora Core 2 for
now, however any comments/feedback on my comments above would
be appreciated.

TIA
Comment 2 d.binderman 2004-01-26 05:55:02 EST
>any comments/feedback on my comments above would
>be appreciated

In the special case of the problems I found, the changes
are relatively trivial, so I'd apply my suggested changes
and continue with the current codebase.

Since I am currently without work, and this package is
in need of help, Redhat would have a strong case to employ me
to fix it ;->
Comment 3 Mike A. Harris 2004-01-26 08:25:26 EST
You can attach a unified diff of the fixes if you like, and I'll look
at them over my next week's worth of updates.
Comment 4 Hans de Goede 2004-09-02 16:46:24 EDT
Hi,

Some time ago I've been doing a lott of investigating into Glide
because I wanted to put life back into my good old voodoo2 card and
the Glide FC is currently shipping only supports Voodoo 3 and 5.

Since the newer sourceforge work doesn't support older voodoos like
mine, that was not an option.

A problem with sticking with the older code was that there we're never
clearly tagged releases out there, so I had todo manual diffs between
all the versions to find out the differences. The conclusion of all
these diffs is that the differences are very small, mostly clean ups.

After all this research I came up with a best of tree:
---
This directory contains:
-a CVS checkout of 10 August 2004 of the glide sourceforge
 CVS modules glide2x, glide3x and Device3Dfx
-and the swlibs directory of the glide3x-3_10_00_30303-src.tgz release
 from sourceforge (part of the Glide3 module)

The purpose of this is to have the latest version of Glide (2 and 3)
which should still work for Voodoo2 boards, to verify this all the
diffs have been manually compared against the official Glide_V2-2.53
by 3Dfx
---

This tree is almost identical too the src-code shipped in FC1, there
are no REAL differences. Except that it also has a glide2 tree (needed
for older HW and progs) and that it can build code working for the
Voodoo2.

The voodoo2 code still needs a cleanup for compiler warnings about
incorrectly used format specifiers and I also had todo some small
fixes to get this compiling on FC3test1 .

It also fixes the strupper code as shown in a previous comment which
not only looks wrong, it actually compiles wrong resulting in a not
working library (atleast some parts),

If you're going to make changes to the glide package as shipped, which
is indeed nescesarry imho. I would like to suggest to use the latest
glide3x cvs bracnh, with swlibs from the Glide3 branch, and then add
on some cleanup and compile fix work.

I'm willing to do the work (I've already done most) and get a
compiling glide3 for Voodoo 2, 3 and 5 (tested only for voodoo2, but
the code for 3 and 5 has no *real* (functionality) changes only
compiler warnings / breakage cleanups.

This would also allow you to compile the tdfx framebuffer driver into
xorg.

I think we're a little late now for the FC3 release, but this could
show up in rawhide shortly after the FC3 release.

BTW tuxracer currently runs fine on Mesa 6.01 on top off my fixed
glide on FC3test1, all compiled from source.

Comment 5 Alan Cox 2004-09-02 16:57:37 EDT
I'd love to get hold of the tree you have. Right now our plans were
somewhere between "dump Voodoo 3D support" and "maybe rescue it if we
have a lot of unexpected free time'.

If you have the Voodoo2 side working thats an unexpected bonus since I
built the new accelerated Voodoo2 2D driver so that one day DRI could
be added to it ;)

Have a Hero badge.
Comment 6 Mike A. Harris 2004-09-02 17:02:02 EDT
/me wonders what's in the water there ;)
Comment 7 Hans de Goede 2004-09-02 17:37:15 EDT
Hi,

Good to hear that you are concidering my work for inclusion.

I just did a checkout of the the new Glide3 development code
done by Daniel Borca and colleagues on sourceforge, and it seems that
they have been doing some more work since their latest release, they
have a voodoo2 tree now in cvs and even a voodoo 1 / rush tree.

So I guess I have to redo my evalution of which tree is the best one
to invest time in :|

The Daniel Borca looks promising since it is activly maintains, but
the old tree with some quick fixes has proven to work and currently
runs fine on my machine HRMMMMM.

Anyways I assume that I have the time todo some research since that
we're way too late for FC3 right?
Comment 8 Alan Cox 2004-09-02 17:48:27 EDT
For FC3test2 ship yes, for FC3 final no. Especially if your changes
are fairly easy to review.
Comment 9 Hans de Goede 2004-09-03 14:14:25 EDT
Created attachment 103444 [details]
patch against the Glide tree resulting from doing a rpmbuild -bp on the latest srpm, fixing all the compile errors and a few bugs

Well, 

I've done my best to make reviewing my changes as easy as possible:

As I already said the changes between the tree I was using after some
experimenting and the tree in the latest srpm was very small.

So I've taken the tree from the latest srpm as a starting point and reapplied
all the fixes (diff & patch are your friend) which I had todo to the CVS dump I
used originally.

This patch is the result of one day of hacking and is as unintrusive as it can
be. It is meant to be applied on top of the tree resulting from doing rpmbuild
-bp on the latest srpm and as such should easily intergrate into the latest
srpm.

It makes glide3 compile for the voodoo2 (cvg) 3 (h3) and 5(h5) targets, the
changes to the h3 and h5 target are the same as to the cvg tree, and I've
tested this changes a lott with my original cvs dump, and as said there we're
no functional differences, mainly revision headers and dos2unix related stuff.

I've had the time yet to test Fedora glide3 + this patch on voodoo2 and I won't
do that untill I've submitted this :) I'll get back with the results RSN.
Comment 10 Hans de Goede 2004-09-03 14:34:15 EDT
Well, Mesa works fine but I'm having some troubles with a native glide
app, but downgrading to my previous ok version also results in the
same problems with this native glide app, so I don't know who to
blame, the app or glide.
Comment 11 Hans de Goede 2004-09-04 01:58:17 EDT
I just did some more testing with the broken direct glide using app
(xmame) and the problem is in the app. (I was doing some hacking on
the app too and the original version works fine)

I still need to take a look at the headers which get installed into
/usr/include/glide3, I think I had todo some mods there too to get
Mesa-6 to compile, after that I think this is in a reasonable state to
go into FC3.

What remeans to be done after FC3 is fix a lott of warnings. Alan
maybe you can take a quick look and lett me know which (type of) warnings:
-need fixing before FC3.
-should be fixed after FC3.
-don't need to be fixed at all

I've already modified the CFLAGS to disable some harmless warnings
whihc otherwise totally flood stderr.
Comment 12 Hans de Goede 2004-09-04 05:52:26 EDT
Created attachment 103458 [details]
Improved patch

Improved patch, the old one still contained a few errors in the h5 and cvg
tree, dunno how these slipped through my first compile attempt, but they showed
up when doing a completly clean build when I was trying to actually build an
rpm with these patches.
Comment 13 Hans de Goede 2004-09-04 05:58:14 EDT
Created attachment 103459 [details]
spec filing using my patch and with other improvements

I accidently used the -26 srpm instead of the -33 srpm (WTF are there 2 Glide3
srpms in the Fedora Core Development SRPM tree?)

So my fixes patch also containes a few fixes which where already in the rpm,
since my fixes we're cleaner and or more complete I've just dropped the patches
from the specfile which we're added between -26 and -33 and instead only use my
fixes patch.

I've also made my fixes patch arch independant in the improved version and
removed a few conflicting patches (which are now fixed in an arch indepenent
way) from the ia64 patch. I've tried applying the ia64 patch and then applying
the others on top this works so I've put it back at pos 0, I didn't try
compiling with it though.

Here is the specfile Changelog:
- added Glide3-fixes.patch which:
  * Generally do everything needed to get this to compile on FC3test1 
  * replaces gcc3-patch with a patch which fixes the macros instead of
    the caller of the macros
  * replaces and fixes libtool patch 
  * replaces and improves gcc34 patch
  * also fix this all for voodoo2
  * fixes a bug in g3df.c which caused some of the test programs to fail
- also compile for Voodoo 2 (cvg)
- do the make install for the Voodoo 5 (h5) build not the (h3) since the
  h5 headers define some additional texture types which Mesa 6 needs to compile

- made the symlink point to voodoo2 by default, since the XFree included mesa
  which is used for h3 and h5 knows how to load the correct Glide itself.
  Maybe we should reintroduce glidelink, since the symlink will still be needed

  for native glide apps on h3 and h5.
- removed unused automake version detection macros
- removed Prereq ldconfig, rpm should pick this up automaticly
- removed conflicting parts from glide-ia64 patch, these are all handled
  in an architecture indepent way in Glide3-fixes.patch, move it back to
  position 0.
Comment 14 Hans de Goede 2004-09-04 06:00:57 EDT
Created attachment 103460 [details]
ia64 patch with conflicting parts removed

Glide3 build with the attached patches and specfiles is about as good as I can
get it for FC3 release, can you review the fixes-patch and lett me know what if
anything needs to be done before this can go into FC3?
Comment 15 Hans de Goede 2004-09-04 06:02:46 EDT
Created attachment 103461 [details]
asm patch

One last note when comparing the trees I came across this patch to the asm
code, can some one with better assembler skill sthen me take a look if this
patch is needed?
Comment 16 Hans de Goede 2004-09-07 07:51:52 EDT
Created attachment 103537 [details]
slightly improved improved patch

The latest incarnation of my patch adds a grBufferSwap symbol to the v5 version
of the library (this was already there in the v3 and v2 version) so that all
the versions are binary compatable and so that native glide apps might also
work when  running on a v5
Comment 17 Alan Cox 2004-09-10 10:39:06 EDT
Asm patch looks right for -fPIC
Lookign over other stuff at the moment
Comment 18 Hans de Goede 2004-10-20 04:47:45 EDT
Alan,

I can't find a new package in rawhide?


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