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: