Hide Forgot
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:
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
>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 ;->
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.
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.
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.
/me wonders what's in the water there ;)
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?
For FC3test2 ship yes, for FC3 final no. Especially if your changes are fairly easy to review.
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.
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.
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.
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.
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.
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?
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?
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
Asm patch looks right for -fPIC Lookign over other stuff at the moment
Alan, I can't find a new package in rawhide?