I'm the Fedora maintainer of tremulous and today I've been working on creating a quake3 package for Fedora.
For this quake3 package I've adapteded a patch from tremulous (already send to them) which allows the usage of the system libjpeg instead of using the private copy bundled with quake3. I'm not sure if my current testing of quake3 has actually exercised any code paths which are involved. But the source code changes applied cleanly from tremulous, and with tremulous atleast the jpeg reading part of tr_image.c has been tested (my initial code was wrong and caused clearly visual problems in tremulous).
Created attachment 1525[details]
New patch which makes system jpeg use quake3's Malloc and Free
Okay, here is a new version which makes the system libjpeg use quake's Malloc and Free, just like its done with the included libjpeg copy. This depends on Linux behavior that symbols in the executable will be used first when resolving symbols, even when resolving symbols for the library. I've verified this by adding printf's to these functions, and these got triggered. I don't know if this will work on other platforms so maybe using the system libjpeg should be made Linux only.
This should resolve the problem mentioned with this in bug 2408.
We've already rejected this before. libjpeg hasn't had an official release in nearly ten years so there aren't really any particularly compelling reasons to go down this route. If there are bugfixes/improvements to the libjpeg code that for whatever reason aren't present in ioq3 then feel free to submit patches.
Pros:
* Marginally smaller binary and codebase
* Updates to libjpeg inherited automatically
Cons:
* Extra dependancy
* Different code path needed for platforms that don't support dynamic linking and/or libjpeg
* Extra glue required to deal with the fact libjpeg differs from the static jpeg code with q3
* Bugs introduced by interfering with code that already "just works" on every platform
Created attachment 1524 [details] PATCH: allow usage of system libjpeg