Summary: | games-strategy/freeciv-2.2.0 USE flags (IPv6, sdl-sound) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Boney McCracker <brendlerjg> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Working Freeciv 2.2.0
strace |
Description
Boney McCracker
2010-02-28 06:44:17 UTC
Created attachment 221523 [details]
Working Freeciv 2.2.0
Hi,
I used the freeciv-2.1.11 ebuild, too and I can't reproduce this error. My game is started as expected and working very well. I started a new game as you describe and myde this screenshot to show you that it works.
regards
j0inty
Thanks for the feedback. I uninstalled it, fully updated my system, rebuilt world, reinstalled it, and it still fails. Tried various USE flag changes to no avail. While preparing to specify minimal CFLAGS for the package in /etc/portage/env, I remembered that I already had freeciv-specific CFLAGS, adding "-fno-inline-small-functions" to my normal CFLAGS noted earlier. This was to overcome some kind of bug in 2.1.11 that is (or at least was) documented in Bugzilla). I'll try removing that and see what happens. Okay, after more investigation I know the following: CFLAGS have nothing to do with it. The client isn't freezing; it is waiting for the server to start. If I wait long enough (about 1 minute), the following scrolls off the bottom of the screen: Starting server... Couldn't connect to the server. We probably couldn't start one from here. You'll have to start one manually. Sorry... Starting the server manually works. However, the "New Game" button *should* launch the server. I have changed the bug title to reflect this as the primary problem. Best guess is that it's probably libsdl-1.2.14. Try downgrading your libsdl and see if it helps. (In reply to comment #4) > Best guess is that it's probably libsdl-1.2.14. Try downgrading your libsdl > and see if it helps. I don't think that's it. You see, I also observed this same behavior when I emerged it without USE="sdl", in which I don't think it's using sdl for anything (without USE="sdl", I don't think libsdl is a dependency). It's easy enough to work around (by starting the server manually before starting the game, and then stopping the server manually when stopping the game), but one shouldn't have to do that. Right, if you're talking about freeciv-gtk2 then it's not a problem with libsdl. Maybe try running it under strace: strace -o out `which freeciv-gtk2` and attach the out file. Same bug there Created attachment 221705 [details]
strace
I have attached an strace.
I don't really know what I'm looking at, but from watching the live output as it was running, I think things were going normally up until about line 10875, after I clicked "New Game". That line begins begins a block of out output that is repeated over and over again during what I had previously described as the game "freezing".
"socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
nanosleep({0, 100000000}, NULL) = 0
waitpid(764, NULL, WNOHANG) = 0
time(NULL) = 1267482367
time(NULL) = 1267482367
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=1061, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7756000
read(5, "# /etc/hosts: Local Host Databas"..., 4096) = 1061
close(5) = 0
munmap(0xb7756000, 4096) = 0"
I should point out that: IPv6 is completely disabled on this machine, intentionally. Afterward, the client outputs the crap about not being able to start the server and that you'll have to start one manually.
what's your /etc/hosts look like? (In reply to comment #9) > what's your /etc/hosts look like? > Bingo! On this machine, I seem to have neglected to delete or comment-out the IPv6 localhost alias in /etc/hosts. Thank you. That should have occurred to me. My issue is resolved. Not a bug. Sorry for wasting your time. ok, glad it's working for you. I can't still launch game. My /etc/hosts there: # IPv4 and IPv6 localhost aliases 127.0.0.1 localhost vesta ::1 localhost vesta 192.168.10.107 vesta 192.168.10.21 iunona (In reply to comment #12) What worked for me was commenting out the IPv6 localhost alias, like this: --------------------------------- 127.0.0.1 localhost vesta #::1 localhost vesta 192.168.10.107 vesta 192.168.10.21 iunona --------------------------------- REOPENED FOR CONSIDERATION OF THE FOLLOWING: I don't understand why the application would be using that as a decision criterion for whether it should try to use IPv6, but to me, that seems to be its behavior. Instead, I would expect it to examine the actual network interfaces for the presence of IPv6 addresses. The freeciv-server and freeciv-client man pages say, "IPv6 aware servers [clients] have additional parameter: [ -A|--announce protocol ]", and "Possible values for protocol are: IPv4, IPv6, none". That implies there is such a thing as a "NON-IPv6 aware" server or client. So I would expect to find compile-time configuration switches for this. Examining the source tarball, it is in fact, configurable at compile-time, but it appears to default to having IPv6 enabled. That's not Gentoo-like. Looking at the source config files: -------------------------------------------file "config" --- optional features: ... --enable-ipv6=yes/no/test use IPv6 (WIP) [test] ... ------------------------------------------------------------ And it does *appear* to have the facility to check to see if the system is IPv6-aware: -------------------------------------------file "config" ---- # Check whether --enable-ipv6 was given. if test "${enable_ipv6+set}" = set; then : enableval=$enable_ipv6; case "${enableval}" in yes|no|test) ipv6=${enableval} ;; *) as_fn_error "bad value ${enableval} for --enable-ipv6" "$LINENO" 5 ;; esac else ipv6=test fi if test x$ipv6 != xno ; then ipv6_possible=true for ac_func in gethostbyname2 inet_pton inet_ntop getnameinfo do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" eval as_val=\$$as_ac_var if test "x$as_val" = x""yes; then : cat >>confdefs.h <<_ACEOF #define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 _ACEOF else ipv6_possible=false fi done if test x$ipv6_possible = xtrue ; then { $as_echo "$as_me:${as_lineno-$LINENO}: checking for AF_INET6" >&5 $as_echo_n "checking for AF_INET6... " >&6; } cat confdefs.h - <<_ACEOF >conftest.$ac_ext ---------------------------------------------------------- So it would seem that we can probably avoid the need for an IPv6 USE flag by setting this to "test" by default. However, it looks to me like this is probably defaulting to being enabled (rather than "test"), or the test isn't working. A separate issue related to USE flags: -----------from "config" ------------ CLIENT_GUI_SDL_FALSE CLIENT_GUI_SDL_TRUE AUDIO_SDL_FALSE AUDIO_SDL_TRUE ------------------------------------- The use of the sdl sound plugin and the building of the sdl-based client seem to be two separate-configurable options. I believe the sdl sound plugin is currently the ONLY way to get sound, so we should probably consider have sdl sound enabled by default, with the sdl USE flag serving only to determine whether the sdl *client* is built (or else have two distinct use flags, such as "sdl-sound" and "sdl-client"). Although the SDL client only adds sdl-image as a dependency, it introduces a lot more work into the build. resync and try it again. I think having the ipv6 flag is fine since it makes the choice more explicit for the users. (In reply to comment #14) Excellent. I'm amazed you were able to make those changes so rapidly. It works great. To confirm I observe what you probably intended: It now provides the sdl sound plugin (via USE="sound" enabled by default) independently of the sdl-based client (optionally enabled via USE="sdl"). It also avoids attempting IPv6 communications (via optionally enabled USE="ipv6"), even if the user has erroneous IPv6 entries in their hosts file. Nice work, and thanks again. |