Mupen64, when installed with portage, instantly causes a segmentation fault on run. This is on two of my AMD64 systems. The binary that I download from the Mupen64 site works fine for me on these systems. The backtrace shows that the segfault happens right in main(): (gdb) bt #0 0xf780da2e in readdir () from /lib32/libc.so.6 #1 0x0809c4bf in main () Here is the emerge --info for my main system: Portage 2.1.2-r10 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r0, 2.6.19-gentoo-r5-niskel x86_64) ================================================================= System uname: 2.6.19-gentoo-r5-niskel x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz Gentoo Base System version 1.12.9 Timestamp of tree: Thu, 22 Feb 2007 13:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.31-r3 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 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.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.20 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -fno-ident" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -fno-ident" 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" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" 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" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 apache2 avahi bash-completion berkdb bitmap-fonts bzip2 cairo cdr cjk cli cracklib crypt cups dbus dri dvd dvdr dvdread emboss encode fam fbcon firefox flac fortran gdbm gif gpm graphviz gtk2 hal iconv ipv6 isdnlog java javascript jpeg kde ldap libg++ mad midi mikmod mng modplug mp3 mpeg musicbrainz ncurses nls nptl nptlonly ogg openal opengl pam pcre pdf perl php png ppds pppd python qt3 qt4 quicktime rdesktop readline reflection samba sdl session slp smp speex spell spl ssl subversion svg tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts unicode v4l v4l2 vim-syntax vorbis wifi x264 xcomposite xine xinerama xml xorg xprint xv xvid zeroconf zlib" ALSA_CARDS="intel-hd" 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="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS Reproducible: Always Steps to Reproduce: 1. emerge mupen64 2. run mupen64 Actual Results: mupen64 segfaults Expected Results: mupen64 runs
I think that's the person i talked with yesterday on #gentoo. However i was not being able to reproduce this behaviour. I noticed some minor glitches on amd64 with dir locations and similar things. I even did a -r3 ebuild+patches and filed a bug with it: https://bugs.gentoo.org/show_bug.cgi?id=171716 It does not fix anything which could be crash related though.
Still cannot reproduce this. And as expected, the cosmetic cleanups of -r3 do not change anything inside the binary so it wont be fixed that way. Maybe try with simple "-O2 -pipe" as CFLAGS and no LDFLAGS?
Upgrading from 0.5-r2 to 0.5-r4 seems to fix the problem. Mupen starts as expected now.
