Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 172098

Summary: UT2004 AMD64 is broken for me
Product: Gentoo Linux Reporter: James <aynjell>
Component: [OLD] GamesAssignee: Gentoo Games <games>
Status: RESOLVED WONTFIX    
Severity: normal    
Priority: High    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: ut2004.ini
ut2004.log
NEW log file.

Description James 2007-03-24 21:02:06 UTC
I've found that the x86_64 UT2004 client crashes during every map change.

Reproducible: Always

Steps to Reproduce:
1.emerge ut2004
2.play ut2004 in multiplayer
3.switch maps (the easiest way to induce this is a 1v1 with a 1 kill limit)

Actual Results:  
UT2004 hangs during map at rotation.

Expected Results:  
More killing in a different place? PLZ?

I found that the x86 version (file -L says:
/opt/ut2004/System/ut2004-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped) does not produce this error. During map change it does not hang, and game moves on to next map in rotation as expected. Steps to fix was copy over the 32 bit executable, and then link to the proper libraries in /usr/lib32... I found only openal.so and libSDL had to be linked in order for the game to run as expected.

I felt this was a gentoo bug for one reason: I'm capable of installing the game with portage, and unfortunately, I wasn't able to use portage to force using the 32 bit game client. There should be a way to do this, most relevently, with useflags.
Comment 1 Paul Bredbury 2007-03-24 21:48:21 UTC
UT2004 can easily be made unstable by changes to its config files, so rename ~/.ut2004 and retry. If that doesn't help, attach ~/.ut2004/System/UT2004.log
Comment 2 James 2007-03-24 21:57:53 UTC
Created attachment 114297 [details]
ut2004.ini

(In reply to comment #1)
> UT2004 can easily be made unstable by changes to its config files, so rename
> ~/.ut2004 and retry. If that doesn't help, attach ~/.ut2004/System/UT2004.log
> 

Well, I haven't manually edited the config at all. I've simply been using the menu... and none of the graphical options SHOULD effect the ability to switch between maps when you're serving. I can play on remote servers just fine, but I cannot play on my own server. As for the log... give me a minute or two... I'll have to set it back to 64 bit, and link openal and libsdl correctly again. One minute... here's my config, though.
Comment 3 James 2007-03-24 22:02:09 UTC
Created attachment 114298 [details]
ut2004.log

Looking at it myself, it would seem that it blows up trying to reregister with gamespy?
Comment 4 Paul Bredbury 2007-03-24 22:12:33 UTC
(In reply to comment #2)
> I haven't manually edited the config at all.

I didn't ask you that. Just rename the directory and retry. It's a very quick and useful check.
Comment 5 James 2007-03-24 22:25:31 UTC
Created attachment 114299 [details]
NEW log file.

(In reply to comment #4)
> (In reply to comment #2)
> > I haven't manually edited the config at all.
> 
> I didn't ask you that. Just rename the directory and retry. It's a very quick
> and useful check.
> 
That came off very rude, but I'm going to hold my tongue. game still very much so crashes, out of the box settings.
Comment 6 Chris Gianelloni (RETIRED) gentoo-dev 2007-03-26 15:18:31 UTC
OK.  I need you to test this with the built-in libraries and *not* ones form your system.  We do not support users using libraries that did not ship with the game.  If this problem still occurs with the default config and the default libraries, then please REOPEN this bug.
Comment 7 James 2007-03-26 17:04:18 UTC
Perhaps you misread, sir. I play the game with the default install and default setup. I emerge ut2004 and that's it. I don't go any further than that. What I found worked and got ut2004 working is to use the 32 bit version of ut2004. The 64 bit client exhibiting the bug is using the libraries delivered with the executable, the 32 bit client uses libraries found in /usr/lib32. Oddly enough, the one using libraries not shipped with the executable works better.
Comment 8 Chris Gianelloni (RETIRED) gentoo-dev 2007-03-26 19:12:52 UTC
When using the 32-bit client, you should also be using the 32-bit libraries that ship with the game.  That was my whole point.  If you're using any lib{SDL,openal}.so outside of /opt/ut2004, then you'll need to make it work with the built-in libraries.  I don't care to try to troubleshoot problems with libraries not shipped with the game.
Comment 9 James 2007-03-26 19:44:38 UTC
(In reply to comment #8)
> When using the 32-bit client, you should also be using the 32-bit libraries
> that ship with the game.  That was my whole point.  If you're using any
> lib{SDL,openal}.so outside of /opt/ut2004, then you'll need to make it work
> with the built-in libraries.  I don't care to try to troubleshoot problems with
> libraries not shipped with the game.
> 

You really aren't getting the point of this bug, sir. The point is, the AMD64 version that merges when I "emerge ut2004" does not work correctly. When I serve a game at home and I'm playing in the same client, on map change the game crashes. I can play on remote servers without crashing during a map change, only when I'm serving does this occur. 

The 32 bit libraries and executable I'm using only stands to prove that the bug is isolated to the 64 bit client. The point of this bug, sir, was to propose an easy way of allowing the user to decide whether they want the 32 bit or 64 bit client or not. I rather enjoy using 64 bit gentoo, I have less problems with it, but I don't want 64 bit UT2004, and I can improvise around it, but others will undoubtedly encounter this, and be unable to EASILY change it using portage because we don't offer the option,and I believe we should.
Comment 10 James 2007-03-26 22:46:26 UTC
Anyway, if you guys would LIKE me to test with the distributed 32 bit binary libraries that came with the game, I could. But is it really neccessary when it's completely unrelated to the bug filed? The point is, I would like to see the ability to select which build I want, 32 bit or 64 bit, I'd even possibly work with the ebuild a bit, but it's a bit over my head, I could do it, it's just a lot of work when I know it would be a lot easier for the maintainer himself to do it. Being able to select the 32 bit version of UT2004 over the 64 bit version is advantageous, and my reason for this is the bug exhibited when switching maps. The game crashes regularly and is unstable, and it may be lazy of me to want to be able to just merge it, but darnit, that's the gentoo way, isn't it? Configure-ability, speed, and I'd hope to god stability, yes? 
Comment 11 Paul Bredbury 2007-03-27 06:16:40 UTC
See the ebuilds in bug #159164. Stop ranting.

Funnily enough, there is now a precedent for using the native libs, because the *Midway* UT2004 DVDs don't contain any Linux files (despite having a penguin on the DVD cover).

However, this is the *first* time I've heard the request to use 32-bit libs under amd64. Untold thousands of other users don't need that.

Isn't Google such a wonderful tool:
http://www.unrealadmin.org/server_ini_reference/ut2004
http://www.unrealadmin.org/forums/showthread.php?t=10130
Comment 12 James 2007-03-27 06:30:13 UTC
(In reply to comment #11)
> See the ebuilds in bug #159164. Stop ranting.
> 
> Funnily enough, there is now a precedent for using the native libs, because the
> *Midway* UT2004 DVDs don't contain any Linux files (despite having a penguin on
> the DVD cover).
> 
> However, this is the *first* time I've heard the request to use 32-bit libs
> under amd64. Untold thousands of other users don't need that.
> 
> Isn't Google such a wonderful tool:
> http://www.unrealadmin.org/server_ini_reference/ut2004
> http://www.unrealadmin.org/forums/showthread.php?t=10130
> 

I wasn't so much concerned with using the 32 bit libs, as I was the 32 bit client. The client only requires the 32 bit libs since it doesn't know what to make of the 64 bit libs.I'll see if the two links provide anything useful tommorrow, but the smart assery is unneccesary.

Comment 13 Chris Gianelloni (RETIRED) gentoo-dev 2007-03-27 14:59:05 UTC
OK.  You want a way to select a 32-bit install on a 64-bit machine.

Here's my simple answer.

No.

I have no intentions on putting forth the work to do so and really don't feel it is advantageous for me to spend time on it.  You can try using:
ABI="x86" ACCEPT_KEYWORDS="-* x86" emerge ut2004

If that doesn't work, I'm honestly not interested in "fixing" it, since the problem seems to be solely on your installation.  I cannot duplicate this on multiple AMD64 machines.
Comment 14 James 2007-03-27 17:24:20 UTC
Portage 2.1.2.2 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 x86_64)
=================================================================
System uname: 2.6.19-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Gentoo Base System release 1.12.9
Timestamp of tree: Mon, 26 Mar 2007 23:00:08 +0000
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acl alsa amd64 avi beagle berkdb bitmap-fonts cdr cli cracklib crypt dbus dri dvd dvdr firefox flac fortran gdbm glitz gnome gpm gtk gtk2 hal iconv ipv6 isdnlog jpeg jpg libg++ mad midi mp3 ncurses nls nptl nptlonly ogg pam pcre perl png ppds pppd python readline reflection session smp spell spl ssl svg tcpd theora threads truetype truetype-fonts type1-fonts unicode vorbis xorg zlib" ALSA_CARDS="intel8x0 emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse joystick evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="livedrive_midi" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY


Well then, if you can't reproduce it, then maybe it's a use flag or some other thing I've set that I shouldn't be setting?
Comment 15 Chris Gianelloni (RETIRED) gentoo-dev 2007-03-27 19:34:53 UTC
WONTFIX means just that.  Don't reopen this, please.

There are no USE flags that affect ut2004, other than it's installation (dedicated/opengl).  I would suggest checking your logs (they're in .ut2004) and reporting the problem upstream if you're having further difficulty.