I've add "multilib_toolchain_setup x86" support to the mupen64-0.5 ebuild and it works here on my amd64 box. I also switched it to use the now included glN64, blight_input and jttl_audio. Are the split plugins really needed? They seem to be made for mupen64 0.4 and 0.5 maybe has even newer code included. When using the included plugins only one multilib x86 hack is needed and the emu is playable for most people. Adding multilib x86 to all plugins would be alot of work.
Created attachment 97255 [details] Mupen64 0.5 ebuild which uses included plugins and works on amd64 It's a first attempt. I hope there are no DEPENDs missing. Maybe the glN64 plugin can be wrapped around an opengl keyword, but it's using OpenGL over SDL and the split ebuild also has no opengl as direct dependency.
Ok, after getting mr_bones approval, i added 0.5-r1 to the tree myself. I assign the bug to myself and close it when theres no bad response soon.
many thanks for the ebuild, it compiles fine. i unfortunately get segfaults when using the dynamic recompiler but not with the interpreter, e.g. on http://www.gameasylum.com/download/demos/N64/Fractal.zip (legal public-domain demo rom). is this expected for amd64? emerge --info Portage 2.1.1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.5 Last Sync: Sun, 17 Sep 2006 21:20:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.6-r1, 2.0.28-r1 dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" 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 /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.zie.pg.gda.pl" LANG="en_US.utf8" LINGUAS="en de" 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'" PORTAGE_TMPDIR="/mnt/portage/var/tmp" PORTDIR="/mnt/portage/usr-portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X a52 aac alsa berkdb bitmap-fonts bzip2 cdr cli crypt cscope dlloader dri dvd dvdr elibc_glibc emacs encode flac fortran gif gmp gnutls gpm gtk gtk2 imap imlib input_devices_keyboard input_devices_mouse isdnlog java joystick jpeg kde kernel_linux libg++ linguas_de linguas_en lua mad matroska mbox mng mp3 mpeg ncurses nls nntp nptl nptlonly offensive ogg opengl pam pcre pdf perl png ppds pppd python qt qt3 quicktime readline reflection ruby sasl sdl session slang speex spell spl ssl svg tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_fbdev video_cards_radeon video_cards_vesa vorbis xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Yes, i get the same kind of segfaults when using the dynamic recompiler. However i don't think it's the ebuilds fault and i'm not really into fixing the upstream code. The most i could do is adding a einfo in the post install section. The question is, does it really only happen on amd64 and not x86 too? It's plain 32bit binaries in all cases, so it's weird.
Ok, i've built a binary inside my x86 chroot without portage. It segfaults exactly the same way. They have a bugreport about this and blame gentoo patches: http://www.emutalk.net/showthread.php?t=27871 I bypassed portage and the patch (which only changes share and lib paths) and it still segfaults after initializing the dynamic recompiler.
I just tested with their official linux binaries and it's the same. So i think we're on the safe side with our ebuild.
Dynamic recompiler works by turning NX/XD off on boot (append noexec=off to kernel parameter line). So my guess is that mupen64 is probably not correctly setting memory permissions on the memory mappings where it places the recompiled code and then executes it there. I'll try and have a look at the code to see if it is possible to apply a small patch to fix this (if this is indeed the issue).
Closing this one. The ebuild is in CVS. If anyone gets a patch for the dynamic recompiler NX issue, please contact me.
