Subject: pkg/24024: ...pkgsrc/games/xdoom has AMD64 problems. (patches available)
To: None <gnats-bugs@gnats.netbsd.org>
From: Richard Rauch <rkr@socrates.olib.org>
List: netbsd-bugs
Date: 01/08/2004 10:53:58
>Number: 24024
>Category: pkg
>Synopsis: ...pkgsrc/games/xdoom has AMD64 problems. (patches available)
>Confidential: no
>Severity: critical
>Priority: low
>Responsible: pkg-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jan 08 16:54:01 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: Richard Rauch
>Release: NetBSD 1.6ZG
>Organization:
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
>Environment:
System: NetBSD socrates 1.6ZG NetBSD 1.6ZG (socrates) #1: Wed Dec 31 15:24:34 CST 2003 root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/socrates amd64
Architecture: x86_64
Machine: amd64
>Description:
On NetBSD/amd64, the xdoom game from pkgsrc does not work.
After patching several files to deal with type-abuse
issues (one problem was left unresolved for lack of
enthusiasm, but it may or may not be a real problem,
depending on whether any upper-32 bits are ever used
in pointers), the program still does not run.
It complains about sound (errno 22, from memory) not
being available, and then freezes early (about 1 second
after starting).
The unresolved bug has to do with storing a pointer into
an {int} variable. Fixing it would involve changing at
least one data structure and a number of variable types.
Probably easy, but since I have smaller PR's with patches
outstanding for other pkgsrc entries already, I thought
that I'd see if there was interest before bothering deal
with the last problem. (I'm moreso inclined since the end
result doesn't run anyway.)
>How-To-Repeat:
Compile. Doom go boom.
>Fix:
If memory serves, the original code compiled with numerous
warnings, and the bits that I modified looked dodgy. I do
not think that there were any compiler errors, though.
The code basically assumes that {sizeof int == sizeof void *;}.
This works for 32-bit systems like i386, but fails on AMD64
where pointers are 64-bit.
Most of these had fairly straightforward problems and solutions,
I think. One of them is a bit more involved, since it is
tied up into a hokey method used to stitch numerous global
variables into the appearance of some kind of order.
Additionally, there are numerous warnings about possibly
uninitialized variables; I did not address those as a spot-
check suggested that they were fine, and if they were really
problems, they would bite everyone.
Patches for what I did are available, though collecting them
is a pain if they aren't going to be used anytime soon. They
do not seem to completely fix the software, and I am not that
deeply concerned about it. (^&
>Release-Note:
>Audit-Trail:
>Unformatted: