Bug#679330: ioquake3: Add support for GNU/Hurd

Svante Signell svante.signell at telia.com
Thu Jun 28 21:25:54 UTC 2012


On Thu, 2012-06-28 at 09:03 +0100, Simon McVittie wrote:
> On 27/06/12 23:10, Svante Signell wrote:
> > The attached patch adds support for the GNU/Hurd architecture
> 
> Thank you for porting it. Do the resulting binaries work correctly? In
> particular, can Linux clients join a Hurd dedicated server and
> interoperate correctly?

Will test soon, bbl.

> To test it, you'll need a very similar patch for openarena (the build
> system is almost identical). 

I have now patched and built openarena. Care for a new bug report?

> You could also use Quake III Arena if you
> own a copy, 

Yes, I happen to have one. Don't know what to install from the CD
though, the pak0.pk3?? file and ?

> but openarena is a better test anyway, because our patched
> version exercises the native-plugin-loading code path.
> 
> My main concerns about things that might not work or interoperate are:
> 
> * networking (BSD sockets implementation)

Will test that out.

> * graphics/sound, for the client (does Hurd have any accelerated 3D?
>   If not, it's likely to be unplayable - seconds per frame rather than
>   frames per second)

Is it the server or client that provides the audio/video? From your
question I guess it is the client. Unfortunately Hurd does not have 3D
support yet, so it will probably be seconds per frame.

> * native-code game logic loading (debian/q3arch, Makefile and
>   q_platform.h all need to end up with the same name for the OS and
>   architecture)

See below.

> If Hurd lacks accelerated 3D, it might make sense to only ship
> ioquake3-server, and leave out ioquake3.

Does it make any harm if the client is built? I don't think people will
try the client until 3D video is supported.

> > +ifeq ($(COMPILE_PLATFORM),gnu)
> > +  COMPILE_ARCH=x86
> > +endif
> 
> This part is (or should be) unnecessary, and could break on hurd-* other
> than hurd-i386. For some reason the ioquake3 build system refers to
> "i386" and "x86_64" on Linux and kFreeBSD (and I think you should follow
> this naming convention for Hurd too), but "x86" and "x64" on Windows.

Yes, it is not needed, I have built ioquake3 without that part. Should I
a provide an updated patch?

> Because you patched the "Linux" case to pick up Hurd as well as Linux
> and kFreeBSD, if you take this part out, the "Linux" logic should still
> apply. (When upstream say Linux they really mean GNU/anything.)
> 
> What does this:
> 
>     uname|sed -e s/_.*//|tr '[:upper:]' '[:lower:]'|sed -e 's/\//_/g'
> 
> (used upstream to set COMPILE_PLATFORM) return on Hurd? Hopefully it's
> "gnu". 

Yes, the answer is gnu because uname results in GNU.

> We don't use this in Debian because we override it with
> "debian/q3arch platform BUILD", but for the patch to be usable upstream,
> they should return the same thing. (For instance, on Linux, q3arch has
> to replace the linux-gnu from the GNU tuple with the linux that the
> Makefile expects).

OK.






More information about the Pkg-games-devel mailing list