Dolphin is an open-source Nintendo GameCube and Wii emulator for Microsoft Windows, Linux and Mac OS X (Intel-based), it is the first emulator to successfully run commercial GameCube and Wii games. It is currently the only emulator capable of running commercial Wii games and it is free software under the GPL 2.0. (c) wikipedia with lack of conventional releases in favor of svn revisions, gentoo is the most suitable distro for its use. make no mistake - it is old, tested piece of software. put your ebuilds in tree now and, maybe, we will avoid dying-off of opengl (say gnu/linux) developers as if with some other, unfortunate, project Reproducible: Always Steps to Reproduce: 1.eix \^dolphin$ 2.emerge -va dolphin Actual Results: frustration Expected Results: [ebuild R ] games-emulation/dolphin-9999 USE="openal portaudio -bluetooth -docs" 0 kB example ebuild coming soon
Created attachment 201298 [details] games-emulation/dolphin/files/Dolphin.png menu icon striped of from .ico
Created attachment 201299 [details, diff] games-emulation/dolphin/files/dolphin_skip-bluetooth.patch patch to properly skip wiimote plug-in if bluetooth support is not present
Created attachment 201300 [details] games-emulation/dolphin/dolphin-9999.ebuild [X] EAPI=2 [!] software does not yet have proper multi-user support [!] software does not yet have proper building and installation scripts [#] note that dependency list is taken from official building instructions but resulting binary has much larger linking list therefore it may be expanded [#] svn repository contain too many redundant sources of dependencies like wxGTK which is not used by us, gnu-people, so way to skip them would be nice
Created attachment 201302 [details] games-emulation/dolphin/dolphin-9999.ebuild [X] put in\rewrite invalid comments
Created attachment 202235 [details, diff] games-emulation/dolphin/files/dolphin_skip-bluetooth.patch updated for newest revisions
Created attachment 219615 [details] games-emulation/dolphin-9999-r2.ebuild [X] updated for recent changes [!] patch removed in favor of sed [!] Dolphin.png renamed in dolphin-emu.png
hello Sergey! Thanks a lot for your continuous work on maintaining this ebuild. If you like you could join our gamerlay overlay and maintain it there. For review and contact please join our #gentoo-gamerlay irc on freenode.
It fails to configure : Using pkg-config for cg... no Looking for lib Cg... no Plugin_VideoOGL must have cg and cggl to be build It did install the dependency : media-gfx/nvidia-cg-toolkit-2.1.0017 ---- Emerge info : Portage 2.1.8.3 (default/linux/amd64/10.0/desktop, gcc-4.4.3, glibc-2.11-r1, 2.6.33-gentoo x86_64) ================================================================= System uname: Linux-2.6.33-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T9800_@_2.93GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 14 Mar 2010 18:15:03 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p2 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1, 3.1.1-r1 dev-python/pycrypto: 2.1.0 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -msse4.1 -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -msse4.1 -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache collision-protect cvs distlocks fixpackages news parallel-fetch preserved-rebuild protect-owned sandbox sfperms strict unemerge-orphans unmerge-logs unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ " LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en fr ja en_US fr_FR" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/mpd /usr/local/portage/layman/sunrise /usr/local/portage/layman/berkano /usr/local/portage/layman/jokey /usr/local/portage/layman/qting-edge /usr/local/portage/layman/kde /usr/local/portage/layman/science /usr/local/portage/layman/gamerlay /usr/local/portage/gbin /usr/local/portage/gfxboot" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac aalib acl acpi alsa amd64 aotuv ares asf avahi bash-completion berkdb bluetooth branding bzip2 cairo cdaudio cdr cjk cli consolekit cracklib crypt cups cxx dbus directfb divx4linux dri dts dv dvd dvdr dvdread eds emboss emul-linux-x86 encode esd exif fam fbsplash ffmpeg firefox flac fortran gcj gd gdbm geoip gif glitz gpm gstreamer gtk gtk2 hal htmlhandbook http i8x0 iconv idn ieee1394 imagemagick jack java java6 javascript jfs joystick jpeg jpeg2k kde kdexdeltas kipi laptop libcaca libnotify lzma mad midi mikmod mmap mmx mng modplug modules mp3 mp4 mpeg mplayer mudflap multilib musepack musicbrainz ncurses networkmanager nls nptl nptlonly nsplugin ntfs obex ogg oggvorbis openexr opengl openmp pam pch pcmcia pcre pdf perl png policykit postgres ppds pppd python qt3support qt4 rdesktop readline reflection reiserfs samba sasl scanner sdl session socks5 speex spell spl sse sse2 sse3 ssl startup-notification svg sysfs tcpd theora threads thunar tiff truetype unicode usb usepackagedmakefiles v4l v4l2 vcd vhosts vorbis wavpack wifi wmf x264 xcb xcomposite xine xinerama xorg xpm xulrunner xv xvid xvmc zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en fr ja en_US fr_FR" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 223675 [details] media-gfx/nvidia-cg-toolkit-2.1.0017.ebuild that's probably because gentoo people decided one day to move nvidia-cg in different place and i didn't agreed... use this ebuild as work-around which will put nvidia-cg in its former place but dolphin ebuild probably should be changed to work with "new" place. it should have worked because nvidia-cg's new path should have been added in ld.so.conf and it should have autodetected it there. that's why i'm not agree with this decision
I get an error when the emerge process tries to install the executable files. doexe: /var/tmp/portage/games-emulation/dolphin-9999-r2/work/dolphin-9999/Binary/Linux-x86_64/dolphin-emu does not exist Which makes sense, since the executable is named dolphin-emu-nogui. This suggests me a couple of questions: - why is it building the nogui version? - how do I build the GUI version? I don't see any relevant USE flags nor conditional statements in the ebuild. Additional info: USE="bluetooth openal portaudio -docs" arch x86_64 used the nvidia-cg-toolkit provided here Thanks in advance.
and your answers are in the heads of developers who decided to change its name AGAIN... keep up with their thoughts then or wait until i or someone else will "fix" it.
> keep up with their thoughts then or wait until i or someone else will "fix" it. Got it, thanks. I'll try fixing it myself.
(In reply to comment #10) > I get an error when the emerge process tries to install the executable files. > > doexe: > /var/tmp/portage/games-emulation/dolphin-9999-r2/work/dolphin-9999/Binary/Linux-x86_64/dolphin-emu > does not exist > > Which makes sense, since the executable is named dolphin-emu-nogui. This > suggests me a couple of questions: > > - why is it building the nogui version? > - how do I build the GUI version? > > I don't see any relevant USE flags nor conditional statements in the ebuild. > > Additional info: > > USE="bluetooth openal portaudio -docs" > arch x86_64 > used the nvidia-cg-toolkit provided here > > Thanks in advance. > Using eselect helped me: richMini ~ # eselect wxwidgets list Available wxWidgets profiles: [1] gtk2-unicode-release-2.8 * richMini ~ # eselect wxwidgets set 1 Setting wxWidgets profile to gtk2-unicode-release-2.8 after that the GUI was built, no modifications needed. By the way I built it with in-portage nvidia-cg, will try if it works well too. And don't forget to rename that icon! Made me many headaches...
> Using eselect helped me: > > richMini ~ # eselect wxwidgets list > Available wxWidgets profiles: > [1] gtk2-unicode-release-2.8 * > richMini ~ # eselect wxwidgets set 1 > > Setting wxWidgets profile to gtk2-unicode-release-2.8 > > after that the GUI was built, no modifications needed. By the way I built it > with in-portage nvidia-cg, will try if it works well too. And don't forget to > rename that icon! Made me many headaches... > Thanks for both tips! They lead me to a clean emerge. Now I'm wondering how to convince dolphin-emu to look for plugins in the install directory instead of the user's home and I get a segfault when opening an ISO...
looks like they more and more trying to make it multi-user but result is still ugly. ideally, they should search their libs (plugins) in $LDPATH/<dolphin>/, put user configs in ~/.<dolphin> and only keep shared stuff in one same dir, preferably /usr/share/<dolphin> with all of them being optionally redefined in configure-time. until they come up with something coherent it is ungrateful job to make it search something somewhere via patches/ebuild magic or to relocate stuff from one directory. you should point directory with your iso-files in the config menu, then choose plugin options. if it segfaults when you trying to run the game then it just a bad code. if in other time - it is a very bad code or we missed something.
Now maybe you can help me? I tried this with the nvidia-cg-toolkit in portage as well as with the one in this bug. I start the app and... nothing happens. It sucks CPU as my fan starts spinnng faster, but no output. I tried strace, and I get lots of "too many open files" messages, which seem to cycle... Any ideas? Portage 2.1.7.17 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.30-tuxonice-r6-richBOOK i686) ================================================================= System uname: Linux-2.6.30-tuxonice-r6-richBOOK-i686-Intel-R-_Core-TM-2_Duo_CPU_T7250_@_2.00GHz-with-gentoo-1.12.13 Timestamp of tree: Mon, 29 Mar 2010 00:45:03 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1 dev-python/pycrypto: 2.1.0_beta1 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.6.3, 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA PUEL skype-eula" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests candy distlocks fixpackages news nodoc noinfo parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="de_AT.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/armagetron /home/chain/portage" SYNC="rsync://ns1.rpgfiction.net/gentoo-portage" USE="X a52 aac acpi alsa apm avahi bash-completion berkdb bluetooth bzip2 cdda cddb cdr cjk cli consolekit cracklib crypt css cups cxx dbus dri dts dvb dvd dvdr emboss encode evo exif fam ffmpeg firefox foomaticdb fortran gdbm gif gnutls gphoto2 gpm gps gstreamer hal iconv idn ieee1394 imap ipv6 jabber jack javascript jikes jingle jpeg kde kdehiddenvisibility libnotify libwww mad memlimit mikmod mime minimal mmx mng modplug modules mozilla mp3 mp4 mpeg mplayer mtp mudflap musicbrainz ncurses nls nocd nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3support qt4 quicktime readline reflection rss samba scanner sdl semantic-desktop session sid slang smartcard smp spell spl sse sse2 ssl startup-notification svg sysfs taglib tcpd thunar tiff timidity truetype unicode usb v4l v4l2 vcd vdpau vorbis wifi win32codecs x264 x86 xcomposite xft xine xinerama xml xorg xpm xscreensaver xsl xulrunner xv xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FOO2ZJS_DEVICES="lm500" INPUT_DEVICES="evdev keyboard mouse synaptics wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" QEMU_SOFTMMU_TARGETS="arm i386" QEMU_USER_TARGETS="arm i386" RUBY_TARGETS="ruby18" SANE_BACKENDS="net" USERLAND="GNU" VIDEO_CARDS="nvidia nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Here is a bad solution for your problem: Replace scons verbose=true || die with scons verbose=true flavor=debug || die and change local bindir="${S}/Binary/$(uname -s)-$(uname -m)" to local bindir="${S}/Binary/$(uname -s)-$(uname -m)-debug" Now it works :-) Nelvin
Nice emulator and thanks for the ebuild. One small flaw is that it fails to install if '-bluetooth' USE flag is set: >>> Install dolphin-9999-r2 into /var/tmp/portage/games-emulation/dolphin-9999-r2/image/ category games-emulation !!! dolib: /var/tmp/portage/games-emulation/dolphin-9999-r2/work/dolphin-9999/Binary/Linux-i686/lib/* does not exist * ERROR: games-emulation/dolphin-9999-r2 failed: * failed to install libraries * * Call stack: * ebuild.sh, line 48: Called src_install * environment, line 2953: Called die * The specific snippet of code: * dogameslib "${bindir}"/lib/* || die "failed to install libraries"; This is because Binary/Linux-i686/lib/ is not created if bluetooth (WiiMote) support is disabled. Perhaps we need to amend the build from: dogameslib "${bindir}"/lib/* || die "failed to install libraries" to read: use bluetooth && \ dogameslib "${bindir}"/lib/* || die "failed to install libraries" Thanks :)
On 2nd thought, to be future proof it may be better to just check that Binary/Linux-i686/lib/ exists before issuing dolib on it. Or remove the '|| die ...'
yep [ -d "${bindir}"/lib ] && $(dogameslib "${bindir}"/lib/* || die) or if [ -d "${bindir}"/lib ]; then dogameslib "${bindir}"/lib/* || die fi will do nicely, probably
OK it's compiling and installing well with '-bluetooth' set. But at runtime the emulator complains with a dialog box popup: "Error loading plugins/libPlugin_Wiimote.so: can't find file" Clicking on 'OK' then segfaults the emulator. So it seems that bluetooth support is only being partially disabled for '-bluetooth'.
yes, we have to either dig deeper and remove it carefully or gave up and make bluez as mandatory requirement. which nor i nor you people, probably, are too excited about :) as Gentoo users, we should gave up since we cannot continue stripping out dependency bits upstream keeps pushing. as Dolphin users, we maybe should recommend upstream to make bluetooth and all non-Gamecube (Wii) stuff completely and hack-free optional while it's not too hard.
Hi guys, Many thanks for this ebuild ! Even if it can't run isos, i never success to build Dolphin from source. But i've encountered little issues : 1. extra qualification error ---> fix by adding line : sed -i "s/NetPlay::/ /" Source/Core/DolphinWX/Src/NetPlay.h 2. failed install librairies ---> fix according to Sergey Kondakov comment : if [ -d "${bindir}"/lib ]; then dogameslib "${bindir}"/lib/* || die fi 3. Failed doicon ; it doesn't find PNG icon ---> fix using xpm file found in resources directory by modifying the line like this : doicon "${S}/Source/Core/DolphinWX/resources/Dolphin.xpm" || die 4. When running Dolphin with the desktop menu entry, it doesn't find plugins ---> fix by modifying the line like this : make_desktop_entry "${PN}" "${name}" "Dolphin.xpm" "Game;Emulator" "/opt/${PN}" So, the frontend runs well, but launching ISOs fails. Hopefully a fully running emulator for the next time !
Hi, For my 1. bug this has been fixed by dolphin-emu's contributor today : http://code.google.com/p/dolphin-emu/source/detail?r=5431 So the ebuild doesn't need anymore my fix. Forget about it.
Created attachment 230651 [details] dolphin-bin-2.0.ebuild
(In reply to comment #25) > Created an attachment (id=230651) [details] > dolphin-bin-2.0.ebuild It looks like this ebuild doesn't work on x86_64 : !!! doins: /var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/Linux-x86_64/user does not exist install: cannot stat `/var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/Linux-x86_64/sys': No such file or directory !!! doins: /var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/Linux-x86_64/sys does not exist install: cannot stat `/var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/Linux-x86_64/plugins': No such file or directory !!! doins: /var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/Linux-x86_64/plugins does not exist * ERROR: games-emulation/dolphin-bin-2.0 failed: * failed to install * * Call stack: * ebuild.sh, line 54: Called src_install * environment, line 3012: Called die * The specific snippet of code: * doins -r "${bindir}"/{user,sys,plugins} || die "failed to install"; Simply the arch name should be hardcoded perhaps : root@sal:/usr/local/portage/gbin/games-emulation/dolphin-bin# ll /var/tmp/portage/games-emulation/dolphin-bin-2.0/work/Binary/ total 4 drwxr-xr-x 6 portage portage 4096 Apr 11 17:51 Linux-i686
Created attachment 230667 [details] corrected to get the amd64 version on x86_64 Corrected the problem I just pinpointed. I also fixed some dependencies but it is still not working, it uses a non-existent libportaudio.so.0 for example. When I soft linked the libportaudio.so.0, it complained about libwx_gtk2u_aui-2.8.so.0. So probably again a tweak to do in the dependencies. ./dolphin-emu: relocation error: ./dolphin-emu: symbol _ZN12wxAuiToolBar12ms_classInfoE, version WXU_2.8 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference
Created attachment 230671 [details] games-emulation/dolphin-9999-r3.ebuild ebuild with aforementioned fixes. and, yep, using binary stuff on linux, and especially on Gentoo and not build by distro maintainers, is a pain...
(In reply to comment #28) > Created an attachment (id=230671) [details] > games-emulation/dolphin-9999-r3.ebuild > > ebuild with aforementioned fixes. > > and, yep, using binary stuff on linux, and especially on Gentoo and not build > by distro maintainers, is a pain... > This one still not work for me, it relates to my wxGTK version/use flags I guess. I have this version with those flags : root@sal:/usr/local/portage/gbin/games-emulation# emerge -pv wxGTK These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/wxGTK-2.8.10.1-r5 USE="X opengl pch sdl -debug -doc -gnome -gstreamer -odbc" 0 kB And the error while compiling dolphin is : g++ -o Binary/Linux-x86_64/dolphin-emu -Wl,-rpath=/var/tmp/portage/games-emulation/dolphin-9999-r3/work/dolphin-9999/Binary/Linux-x86_64/lib/ -pthread -Wl,-O1 -Wl,--as-needed -pthread Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/BootManager.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/cmdline.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/AboutDolphin.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ARCodeAddEdit.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ConfigMain.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/Frame.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/FrameAui.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/FrameTools.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/LuaWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/LogWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/GameListCtrl.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/Globals.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/HotkeyDlg.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ISOFile.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ISOProperties.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/MemcardManager.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/MemoryCards/GCMemcard.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/PatchAddEdit.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/CheatsWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/stdafx.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/WxUtils.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/MemoryCards/WiiSaveCrypted.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlay.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlayClient.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlayServer.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/X11Utils.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/Main.o -LBuild/Linux-x86_64-release/libs -Llibs -LBinary/Linux-x86_64/lib -L/usr/lib64 -lSDL -lbluetooth -lao -lpthread -ldl -lasound -lportaudio -lX11 -lXrandr -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu-2.8 -ldebwx -ldebugger_ui_util -lcore -llzo2 -ldiscio -lbdisasm -lvideocommon -linputcommon -lcommon -llua -lz -lsfml-network Build/Linux-x86_64-release/libs/libdebwx.a(RegisterView.o): In function `CRegisterView::CRegisterView(wxWindow*, int)': RegisterView.cpp:(.text+0x3e): undefined reference to `wxGridNameStr'
(In reply to comment #29) > This one still not work for me, it relates to my wxGTK version/use flags I > guess. > I have this version with those flags : > root@sal:/usr/local/portage/gbin/games-emulation# emerge -pv wxGTK > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] x11-libs/wxGTK-2.8.10.1-r5 USE="X opengl pch sdl -debug -doc > -gnome -gstreamer -odbc" 0 kB > ebuild 9999-r3 works for me on x86_64. Same version of wxGTK with USE flags: "X gnome gstreamer opengl pch sdl -debug -doc -odbc"
> ebuild 9999-r3 works for me on x86_64. Same version of wxGTK with USE flags: > "X gnome gstreamer opengl pch sdl -debug -doc -odbc" > I just added the 2 gstreamer & gnome and it still fails. I found this error upstream : http://code.google.com/p/dolphin-emu/issues/detail?id=1946 There is an ugly workaround. add '-Wl,--no-as-needed' to the LINKFLAGS Do you have those ?
> There is an ugly workaround. > add '-Wl,--no-as-needed' to the LINKFLAGS > Do you have those ? > I never touched link flags, but I'm not extremely familiar with advanced build environments. How can I make sure I don't have those?
Wow ! For me now dolphin can run games, but i can't play it because a modal dialog box appears as soon as i launch the game. The message is : "Can't find file", i don't know why. After validating the message box, it causes segmentation fault. But one thing : Dolphin can't compile if i use nvidia-cg-toolkit-2.1.0017, it doesn't find cg lib, but 2.1.0012 (present in stable branch) it works.
(In reply to comment #33) > Wow ! > For me now dolphin can run games, but i can't play it because a modal dialog > box appears as soon as i launch the game. The message is : "Can't find file", i > don't know why. After validating the message box, it causes segmentation fault. See comment #21 and #22. Is it because you have emerged dolphin with '-bluetooth' ? It needs to have 'bluetooth' USE enabled to work.
(In reply to comment #27) > Created an attachment (id=230667) [details] > corrected to get the amd64 version on x86_64 > Corrected the problem I just pinpointed. I also fixed some dependencies but it > is still not working, it uses a non-existent libportaudio.so.0 for example. > When I soft linked the libportaudio.so.0, it complained about > libwx_gtk2u_aui-2.8.so.0. So probably again a tweak to do in the dependencies. > ./dolphin-emu: relocation error: ./dolphin-emu: symbol > _ZN12wxAuiToolBar12ms_classInfoE, version WXU_2.8 not defined in file > libwx_gtk2u_aui-2.8.so.0 with link time reference Thanks Guillaume, have obsoleted the 1st dolphin-bin-2.0.ebuild. Regarding the bug with version WXU_2.8 not defined in file libwx_gtk2u_aui-2.8.so.0, this has been a problem with wxGTK for many years on all distros that usually resolves itself by re-installing wxGTK. I don't get the libportaudio.so.0 error (nor do I have this file), but that could probably be put down to a quirk with upstream's 64-bit build. The i686 tarball is working a treat here.
(In reply to comment #34) > (In reply to comment #33) > > Wow ! > > For me now dolphin can run games, but i can't play it because a modal dialog > > box appears as soon as i launch the game. The message is : "Can't find file", i > > don't know why. After validating the message box, it causes segmentation fault. > > See comment #21 and #22. > Is it because you have emerged dolphin with '-bluetooth' ? > It needs to have 'bluetooth' USE enabled to work. > Does the bluetooth USE flag make any sense (at least, as of now)? It seems to me that unsetting it breaks the application's core functionality. It seems to me it should be remove until (if ever) Bluetooth support becomes an actual option and not a requirement for the emulator to work.
Created attachment 231265 [details] games-emulation/dolphin-9999-r4.ebuild No more of pesky useless option for you, Mr. Obvious ;)
(In reply to comment #37) > Created an attachment (id=231265) [details] > games-emulation/dolphin-9999-r4.ebuild > > No more of pesky useless option for you, Mr. Obvious ;) > Well done. Now I can enjoy my "error was 'BadDrawable (invalid Pixmap or Window parameter)'" crashes in peace. ;)
(In reply to comment #34) > See comment #21 and #22. > Is it because you have emerged dolphin with '-bluetooth' ? > It needs to have 'bluetooth' USE enabled to work. > I try r4 ebuild version and i get same error ('can't find file'). No more info on output terminal.
*** Bug 320997 has been marked as a duplicate of this bug. ***
Created attachment 233101 [details] dolphin-9999_p5362.ebuild Dolphin fails to compile since SVN revision 5396, see -> http://code.google.com/p/dolphin-emu/issues/detail?id=2727 For this reason, here's a pegged ebuild for r5362 before the fail was committed. Just rename the ebuild to dolphin-9999_p<revision number>.ebuild to get a different revision number.
It's been fixed upstream now, great turnaround from those guys. I'll keep the peg ebuild around for future use, but the 9999-r4 works again now :)
svn ebuilds have been broken by revision 5935: https://code.google.com/p/dolphin-emu/source/detail?r=5935 The gist appears to be that the ebuild explicitly installs dsptool, which is no longer built by default.
Hi, I'm one of the dolphin-emu developers and I compiled it on gentoo on daily basis. (I somehow missed this ebuild though). Some of the issue I saw people encountering on this thread are obviously upstreams ones. You are more than welcome to open an issue about them and I'll personally do my best to fix them. I'm interested in getting dolphin into portage before the coming 2.1 release so feel free to bug me about any remaining issues.
*** Bug 334549 has been marked as a duplicate of this bug. ***
I'm about to post a new 9999-r5 version of the ebuild that contains a number of changes that I think greatly improve the quality and reliability of the ebuild. Before posting, though, I wanted to cover some of the changes. The biggest thing is that I changed the (expected) name of the package to games-emulation/dolphin-emu. I did this for three reasons: 1. it better matches the project name 2. it matches the default binary name 3. it avoids a naming conflict kde-base/dolphin If desired, this could be changed back to games-emulation/dolphin, but you'd need to update the binary and package name in a few places under src_install(). For the reasons listed above, though, I recommend leaving it as dolphin-emy. As for other changes/improvements, it contains, in no particular order: 1. Updated dependencies 2. Support for opencl 3. Support for nowx (building headless version) 4. changed docs -> doc USE flag for consistency with other packages 5. Supports $MAKEOPTS from make.conf for parallel compilation 6. Explicitly enable/disable shared libraries where appropriate for consistency 7. Disable verbose compilation as it didn't seem to add anything worthwhile 8. Binary and data files now installed under /usr/share/games ($GAMES_DATADIR) rather than /opt (which means you'll need to manually copy your preferences over after upgrading) 9. Disabled dsptool installation, which was causing failure since that's no longer built by default 10. Use games_make_wrapper to generate wrapper script in /usr/games/bin - this is critical as the previous version had some major deficiencies (see: http://code.google.com/p/dolphin-emu/issues/detail?id=3268&can=1#c5) 11. Restricted group write permissions to ./user rather than all subdirectories 12. Moved warning messages to pkg_postinst() I think that should cover it. These changes add up to, in my opinion, a much more robust ebuild, but there are certainly some things that could still be improved. See next post: this message ended up being far too long with everything contained in one post.
As mentioned previously, there are still some improvements that should be made. In particular: 1. The user configuration directory stuff, obviously, still needs to be fixed by moving preferences to ~/.dolphin-emu rather than a shared system directory. Dolphin already sort-of supports this, but it's buggy and unusable currently. Specifically, there are three issues: 1a. If launched from the directory containing the dolphin-emu binary (ie., $PWD == /usr/share/games/dolphin-emu), dolphin will use ./user for configuration. Otherwise, it will (try) to use ~/.dolphin-emu 1b. Support for ~/.dolphin-emu is not complete, as preferences do not get saved and it generates multiple SYSCONF error messages on each startup 1c. Dolphin will not find its plugins unless unless executed from its own installation directory, making it impossible to run games otherwise I'm going to attempt to work with upstream to get this fixed. 2. opencl does no dependency resolution, because I'm not sure what to verify. If opencl is already supported by your video card and driver, it should work fine here. If not, compilation will likely fail with USE=opencl. Is it enough to add something like: RDEPEND="|| (x11-drivers/nvidia-drivers x11-drivers/ati-drivers)"? 3. Compilation and linking against wxGTK is... flaky. See here. comments 3-7, for the details: http://code.google.com/p/dolphin-emu/issues/detail?id=3268 In the end, the only way I could work around this was by creating a quickpkg for wxGTK-2.9.10 from my laptop and installing it on my desktop, and also manually copying over /usr/lib/libpng12.so.0, which was still used by wxGTK for some reason even through the system has been upgraded to libpng-1.4.x. Otherwise, it seems to be impossible to successfully compile, link, and use Dolphin with any freshly compiled version of wxGTK currently in portage. I would LOVE to hear feedback from anyone that can figure out the wxGTK issue. In general, though, my advice is that if you can currently get Dolphin to successfully install and run, DO NOT reinstall/upgarde wxGTK, as it seems you will not be able to get Dolphin working again after that. Ely, if you're interested in helping out, a fix for issue #1 would be especially useful prior to 2.1. A fix for issue #3 would also be extremely welcome, which is currently tracked (and seems to be ignored) by upstream here: http://code.google.com/p/dolphin-emu/issues/detail?id=1946 I'm not sure how much of 3 is related to Dolphin vs. wxGTK vs. Gentoo, though. Hope everyone finds this info useful. Feedback welcome. :-)
Created attachment 249035 [details] games-emulation/dolphin-emu-9999-r5.ebuild
good job. i did actually write something like that but then deleted it since even a thought of stuff writing somewhere besides /home,/opt,/tmp and /var on my system is pissing me off... now i just wait for them to migrate on cmake and rewrite their build-scripts. it would be cool if they also used consistent case but i don't know how to tell them that over than "DON'T freaking use capital letters in paths, ever!" on their bugtracker which is not very nice, you can imagine.
Created attachment 249123 [details] games-emulation/dolphin-emu-9999-r6.ebuild Great news: this new ebuild -r6 ebuild fixes the shared user configuration problem! When running Dolphin, all preferences are now saved to ~/.dolphin-emu. W00t! This, functionally, is the only change from my last ebuild, although the ebuild itself is substantially different (the new build option required a completely different installation process). I also, obviously, removed all of the group writable stuff since that's no longer required. I think this ebuild is pretty solid. My only major concern at this point is the wxGTK issue I mention previously. Can someone please test that? It can be done in four easy steps: 1. Install dolphin-9999-r6 and verify that it works now on your system 2. quickpkg wxGTK (just to be safe) 3. Reemerge wxGTK with gcc-4.4.3 4. Reemerge dolphin-9999-r6 - does it still build and install properly? I'd really love to get feedback on this.
shouldn't "nowx" flag be actually "+wxwidgets" as with every other wxGTK-dependent software ? i remember reading somewhere about Gentoo incentive to get rid of "noX" flags for good. it also fails at install phase for me with: scons: done building targets. * A game was detected that is setuid root! <list of all directories in /var/tmp/portage/games-emulation/dolphin-emu-9999-r6/image///usr/share/games/dolphin-emu/data/{user,sys}> die "refusing to merge a setuid root game" and, by the way, what exactly this scons thing building there in "scons install" ?
Linking with wxGTK is broken for me. I'm pretty sure this has to do with --as-needed, as someone suggested in the Dolphin issue tracker. I think the problem lies in libdebwx using wxGTK, but not being linked to it. In the final dolphin-emu linking, libdebwx and the wxGTK libs are passed to g++. When --as-needed is used, I think libdebwx is dropped because it's not used directly by dolphin-emu, and the missing symbols are not resolved, thus the failure. I tried filtering --as-needed from the ebuild, but with no success. Can someone give this a try?
(In reply to comment #51) > shouldn't "nowx" flag be actually "+wxwidgets" as with every other > wxGTK-dependent software? Yes, probably. I wasn't familiar with the wxwidgets flag, though, so I just used the name of the build option. This can definitely be changed. > it also fails at install phase for me with: > <SNIP> Weird. I have no idea what'd cause that, and I haven't seen it myself yet. Will need to investigate. Out of curiosity, what happens if you first emerge -C your existing copy of dolphin? That *shouldn't* matter, but then again you shouldn't be getting that error. > and, by the way, what exactly this scons thing building there in "scons > install" ? The first call to scons, in src_compile(), builds all objects. The second call, in src_install(), links objects into the final executable and "installs" the files to the appropriate location under ${D}. I'm not sure why scons behaves that way, but the two separate calls seem to be necessary. I'm open to suggestions for improvement, though.
(In reply to comment #52) > Linking with wxGTK is broken for me. I'm pretty sure this has to do with > --as-needed, as someone suggested in the Dolphin issue tracker. I saw this as well, but the "solution" (discussed here: http://code.google.com/p/dolphin-emu/issues/detail?id=1946) doesn't seem to apply to current builds (see comment 10 from that thread). I've not been able to workaround the problem, and even if we could get that --no-as-needed thing to work would we really want to use that as a solution? According to one of Dolphin's own devs, "it is VERY unstable." The only way I was able to get this working on my desktop was to do a quickpkg of wxGTK from my laptop and moving that over. This is, obviously, far from an optimal solution. > I think the problem lies in libdebwx using wxGTK, but not being linked to it. Sounds reasonable. Any idea how to fix it? ;-) I spent some time trying to figure out what libdebwx was doing, but completely failed to come up with anything useful. Most of this linking stuff is far beyond me, though, which is why I'm hoping to get some actual developers looking into it.
> (In reply to comment #51) > Weird. I have no idea what'd cause that, and I haven't seen it myself yet. > Will need to investigate. i'm in shock myself. don't know what to make from it. > Out of curiosity, what happens if you first emerge -C your existing copy of > dolphin? That *shouldn't* matter, but then again you shouldn't be getting that > error. and this is exactly what i did since i used my "games-emulation/dolphin" ebuild and decided to replace it with this one. > The first call to scons, in src_compile(), builds all objects. The second > call, in src_install(), links objects into the final executable and "installs" > the files to the appropriate location under ${D}. I'm not sure why scons > behaves that way, but the two separate calls seem to be necessary. I'm open to > suggestions for improvement, though. > it's on then. when i was playing with scons and dolphin installation a while back it looked if it was rebuilding everything again and then immediately installing. i will try to find out what the hell happening and where suid comes from a bit later.
Created attachment 249197 [details] Updated ebuild which should fix linking problems Ok, I think I fixed the linking problems. At least it's working for me now. I reordered some of the libs in the linking process. This post http://forums.gentoo.org/viewtopic-t-842124-start-0.html saved my day (and my night probably :)
Created attachment 249198 [details, diff] Patch to solve the --as-needed linking breakage You'll need this patch as well.
I still have problems with the plugins now. When I try to open an iso I get "Error loading libPlugin_DSP_HLE.so: can't read info". There's already an open ticket here: http://code.google.com/p/dolphin-emu/issues/detail?id=2786, with a possible (dirty) workaround. Any hints on that?
Awesome news, Carles. Thanks! I'll test it out tonight to verify. As for the plugin problem, I encountered that as well after changing to the new "install=global" build option (which was necessary for proper ~/.dolphin-emu support). I had to add the following to make this work: sed -e 's;LIBS_DIR "dolphin-emu";LIBS_DIR "plugins";' \ -i "${S}/Source/Core/Common/Src/CommonPaths.h" I see that your patch also seems to touch a variable relating to libraries. Maybe its messing with LIBS_DIR somehow? That's the only thing I can think of offhand. To troubleshoot, use strace on Dolphin, click on the DSP configuration button, then exit Dolphin and search the strace output for libPlugin_DSP_HLE.so. It *should* search for it under /usr/share/games/dolphin-emu/lib/plugins/. If it's looking somewhere else, that's a problem. ;-)
I can confirm that the patch Carles provided will allow linking against wxGTK, but I can also confirm the plugin problem. This is different than the problem that I had seen previously: Dolphin isn't reporting that it can't *find* the plugins, it's reporting that it can't *read* the plugins. Strangely, it cant find the OpenGL video plugin, but not any other plugin. No idea why that one's special, nor why it's failing to begin with. I poked around to see if I could find anything obvious, but like I said before, most of this is out of my league. Would appreciate it if, again, someone more experienced could take a look. For what it's worth, it seems to be failing on the GetPluginInfo(info, _rFilename) call on line 231 of Source/Core/Core/Src/PluginManager.cpp. This, in turn, seems to be reading data originally gathered by CPluginManager::ScanForPlugins on line 280 of that same file.
i found out why i was getting error about suid: directories in my DISTDIR containd suid to inherit user right shile i was fetching as root and portage and scons wasn't fixing that and moved them as they was. my ebuild wasn't gicing an error because i was using 'doins' and it was fixing rights. and i wasn't able to realize that because i was too pissed at dolphin to think. and now i also realized that Jared has put binaries and libraries at games shared datadir which is not right. there is '/opt' for that. portage should have just die on that and it would have been right. there is two ways you can install it: 1) you put everything in /opt/$PN and set whatever you want rights there. and you use wrapper to launch binary from there. 2) you put binaries in /usr/games/bin, normal libraries in /usr/games/lib, plugin libraries in /usr/games/lib/$PN and all the rest in /usr/share/games/$PN. for that, you should make sure that program can find all its stuff. and right now dolphin-emu finds its stuff alright when installed with #2 in exception of few issues: 1] scons does not install its data even though there is data_dir info in SConstruct. fix: this should be fixed by proper build system, like cmake or at least properly used scons. 2] looks like it still writes DATA_DIR definition from SConstruct into binary and causes it to search that path and find something there if you have copied data by means like doins. but it still can't properly decide what it wants to fetch from shared datadir and what from homedir. you get ambiguous "SYSCONF" errors and stuff. fix: this should be fixed by following the ruleset like: everytime - first, read from shared datadir, then read from home datadir and overide values, then write in home datadir. that, if you need read a lot from shared datadir and not so much from home. reverse, if its the opposite but you always write to home only or also somewhere in /var if you really need to. proper multiuser configuration was common sense for decades and not so common implementation until recently but, nowadays, even windows has and enforces it. 3] it unable to create folders in ~/.dolphin-emu for itself. like ~/.dolphin-emu/Config embarrassing. fix: check for path availability before trying to write a file there, damn it. create it if not available. always use proper permissions. all of this should be fixed by UPSTREAM. so, help them, please, my fellow comrades ;) about what we, ebuild writers, can do: use way #1 or #2 but don't make bloody pulp out of it. if you use #1 then put stuff in /opt and if #2 - reconcile with errors and work with upstream to fix them. those current errors should not stop you from launching GameCube games if you first will do `mkdir -p ~/.dolphin-emu/Config` and will ignore "SYSCONF" errors. PS: do you have "QA Notice: Files built without respecting LDFLAGS have been detected" message with latest ebuilds ? if you do, then it means that scons does not respect your LDFLAGS and it, probably, does not use FLAGS wxGTK was build with. that may be the source of nasty bugs above and should be fixed with decent set of rules for build system, prefferably, which is also decent.
Created attachment 249247 [details] games-emulation/dolphin-emu-9999-r6.ebuild ebuild, following way #2, with incorporated recent fixes from here. needs "dolphin-emu-9999_fix_build.patch"
(In reply to comment #60) > Dolphin isn't reporting that it can't *find* the > plugins, it's reporting that it can't *read* the plugins. I made some more progress on this. Using ltrace I was able to determine that it fails trying to read all plugins with an undefined symbol error, except on the OpenGL plugin (which is the only one that works). Specifically: libPlugin_Wiimote(New).so: undefined symbol: ba2str libPlugin_VideoSoftware.so: undefined symbol: clCreateCommandQueue" libPlugin_DSP_[HL]LE.so: undefined symbol: alSourcef" Anyone know how to work around this?
(In reply to comment #60) > This is different than the problem > that I had seen previously: Dolphin isn't reporting that it can't *find* the > plugins, it's reporting that it can't *read* the plugins. > > Strangely, it cant find the OpenGL video plugin, but not any other plugin. No > idea why that one's special, nor why it's failing to begin with. I poked > around to see if I could find anything obvious, but like I said before, most nothing strange here. reported forgot to mentions that real issue is "undefined symbol" error which renders library unusable even if it can find it. same linking trouble as with wxGTK only with pulseaudio it seems. same cause, i presume - shitty linking and disrespect for flags of its dependencies and global ones. strange that i don't get those errors since my whole system is build with --as-needed. my wxGTK version, by the way, is 2.9.1 and i don't use pulseaudio. as for fixing it... i don't know, try to run `lafilefixer --justfixit` and reemerge whole system with newest toolchain and --as-needed enabled globally (it's enabled by default recenly) or something.
(In reply to comment #61) > and i wasn't able to realize that because i was too pissed at dolphin to think I think that means you need to relax a bit. :-) > and now i also realized that Jared has put binaries and libraries at games > shared datadir which is not right Why is this not right? I'm certainly not opposed to improvement, but I've seen other games take this same approach. eduke32 and mupen64plus are two examples. > there is '/opt' for that I don't think /opt is appropriate here. From everything I've seen. /opt is mostly (on my system, only) used for binary packages. > 1) you put everything in /opt/$PN and set whatever you want rights there. and > you use wrapper to launch binary from there. This requires "install=local", and breaks the ability to save data to ~/.dolphin-emu. That's why I switched to "install=global", which goes into /usr by default but I modified the build scripts to place under $GAMES_DATADIR > 2) you put binaries in /usr/games/bin, normal libraries in /usr/games/lib, > plugin libraries in /usr/games/lib/$PN and all the rest in > /usr/share/games/$PN. That's essentially what I was going for, but dolphin didn't make it easy. I needed to get assistance from the upstream devs to get as far as I did, as the plugins path is set specially, and separately, from the main SConstruct file. It may be possible to split up the components even further like you're suggesting, but it'll probably take a good bit more tweaking. > 1] scons does not install its data even though there is data_dir info in > SConstruct. I'm not sure what you mean by this. The "scons install" line installs everything perfectly fine. > 2] looks like it still writes DATA_DIR definition from SConstruct into binary > and causes it to search that path and find something there if you have copied > data by means like doins. but it still can't properly decide what it wants to > fetch from shared datadir and what from homedir. you get ambiguous "SYSCONF" > errors and stuff. This should only be an issue with build=local, as everything is *supposed* to be grouped together in expected locations in that configuration. With build=global, Dolphin does properly use ~/.dolphin-emu, and does not generate those SYSCONF messages. > 3] it unable to create folders in ~/.dolphin-emu for itself It does do this, but again it requires build=global. > all of this should be fixed by UPSTREAM. so, help them, please, my fellow > comrades ;) I agree that there are plenty of improvements that can and should still be made upstream, but my -r6 ebuild is, best I can tell from my two systems, solid except for the USE flag issue you mentioned and the wxGTK issue (which Carles has been helping to address). The key was switching to build=global and letting scons install the files itself. This is what my previous comments about rewriting src_install() were referring to. > PS: do you have > "QA Notice: Files built without respecting LDFLAGS have been detected" Actually, I don't, neither with Carles' patch nor without. Not sure why we're seeing something different there.
(In reply to comment #64) > (In reply to comment #60) > > Strangely, it cant find the OpenGL video plugin, but not any other plugin. ack, made a typo there: it CAN find the OpenGL plugin, but not any others. > strange that i don't get those errors since my whole system is build with > --as-needed. my wxGTK version, by the way, is 2.9.1 and i don't use > pulseaudio. That is strange. I did an emerge -e world a couple days ago trying to fix this, so my entire system should be built with --as-needed as well, but I still have the problem. As for 2.9.1, I CAN get Dolphin to build with that, but it's not usable. Any time I select a game in the main browser window, Dolphin instantly crashes. Can you test that and see how it works on your system? Would be very interested to hear if it's different.
Created attachment 249265 [details] games-emulation/dolphin-emu-9999-r8.ebuild I'm attaching my latest rev of the ebuild, named -r8 since Carles used -r7. This version: * changes -nowx to +wxwidgets * incorporates Carles' patch as a sed line, so need need for a separate file * changes installation structure to the following, at Sergey's suggestion: plugins: /usr/games/lib64/dolphin-emu/ user,sys: /usr/share/games/dolphin-emu/ binary: /usr/games/bin/ As noted previously, also dolphin will now link against wxGTK now with Carles' patch, it's still not usable due to the undefined symbol issue with the plugins. I've been troubleshooting this on and off throughout the night, and I'm completely out of ideas at this point. Any additional assistance with that problem would be most welcome.
(In reply to comment #65) > > I think that means you need to relax a bit. :-) that i do ;) > > Why is this not right? I'm certainly not opposed to improvement, but I've seen > other games take this same approach. eduke32 and mupen64plus are two examples. equery f games-emulation/mupen64plus|grep so /usr/games/lib64/mupen64plus/plugins/blight_input.so <and so forth> i don't think so... and eduke32 not even in portage which means its ebuild authors could do whatever they wanted. which does not do it right. this is just something you don't ever do in "Linux" - putting binaries (and libraries are also binaries) all over the place. > That's essentially what I was going for, but dolphin didn't make it easy. I > needed to get assistance from the upstream devs to get as far as I did, as the > plugins path is set specially, and separately, from the main SConstruct file. > It may be possible to split up the components even further like you're > suggesting, but it'll probably take a good bit more tweaking. this is not that difficult but yeh, this whole scons thing gave me a hard time to figure out. surprisingly, apparently it's just looking for plugins in subdirectory "dolphin-emu" in every directory of ldpath. which is exactly what we want from it. > I'm not sure what you mean by this. The "scons install" line installs > everything perfectly fine. doesn't work for me for some reason. maybe doesn't like my path with '/..' in it and skips it, sneaky... thing. > Actually, I don't, neither with Carles' patch nor without. Not sure why we're > seeing something different there. i see it with your ebuild too. do you use custom LDFLAGS in your make.conf ? if not - that's an answer. but if it ignores global LDFLAGS and does not give that notive that means it should be building with --as-needed by default... or doesn't mean anything as with sneaky data_dir issue. (In reply to comment #66) > As for 2.9.1, I CAN get Dolphin to build with that, but it's not usable. Any > time I select a game in the main browser window, Dolphin instantly crashes. > Can you test that and see how it works on your system? Would be very > interested to hear if it's different. not crashes for me on that but i remember that sometime ago it were. can't use it though anyway since it crashes on video plugin for me - OpenGL plugin doesn't like my mesa r600c driver and Software plugind doesn't like my X :) (In reply to comment #67) > Created an attachment (id=249265) [details] > games-emulation/dolphin-emu-9999-r8.ebuild thank you, good job ! scons is such hideous thing - i didn't manage to make it install data properly even there should have been no difference as with your approach. with this ebuild it installs properly and it finds everything and does not give "SYSCONF" errors. it does miss pulseaudio flag and dependency though.
Gosh yes, the scons build system is spectacularly poor. How does one even get it to respect the most basic of LDFLAGS ? Anyway, the build fails if portaudio is installed (regardless of whether 'portaudio' USE flag is enabled or not) as it breaks linking at install time yet again due to it using '--as-needed'. Like this... scons: Building targets ... g++ -o Build/Linux-x86_64-release/Source/Core/Common/Src/Version.o -c -fvisibility-inlines-hidden -Wno-deprecated -O3 -fomit-frame-pointer -fno-exceptions -fno-strict-aliasing -fvisibility=hidden -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wpacked -Wpointer-arith -Wshadow -Wwrite-strings -Wno-array-bounds -Wno-unused-result -fPIC -msse2 -pthread -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE=1 -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -I. -ISource/PluginSpecs -I/usr/include/SDL -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -I/usr/include/alsa -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include/libdrm -IExternals/Bochs_disasm -IExternals/Lua -IExternals/WiiUse/Src -IExternals/SOIL -IExternals/SFML/include -ISource/Core/AudioCommon/Src -IBuild/Linux-x86_64-release/Source/Core/Common/Src -ISource/Core/Common/Src -ISource/Core/Common/Src -ISource/Core/Core/Src -ISource/Core/DSPCore/Src -ISource/Core/DebuggerUICommon/Src -ISource/Core/DebuggerWX/Src -ISource/Core/DiscIO/Src -ISource/Core/DolphinWX/Src -ISource/Core/InputCommon/Src -ISource/Core/InputUICommon/Src -ISource/Core/VideoCommon/Src Source/Core/Common/Src/Version.cpp g++ -o /var/tmp/portage/games-emulation/dolphin-emu-9999-r8/image/usr/games/bin/dolphin-emu -Wl,-O1 -Wl,--as-needed -pthread Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/BootManager.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/AboutDolphin.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ARCodeAddEdit.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/GeckoCodeDiag.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ConfigMain.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/Frame.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/FrameAui.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/FrameTools.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/LuaWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/LogWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/GameListCtrl.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/HotkeyDlg.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ISOFile.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/ISOProperties.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/PatchAddEdit.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/CheatsWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/Main.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/MemoryCards/WiiSaveCrypted.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlay.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlayClient.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetPlayServer.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/NetWindow.o Build/Linux-x86_64-release/Source/Core/DolphinWX/Src/X11Utils.o -LBuild/Linux-x86_64-release/libs -L/usr/lib64 -ldebwx -ldebugger_ui_util -linputuicommon -lmemcard -lGLEW -lSDL -lpthread -lz -llzo2 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu-2.8 -lbluetooth -lasound -lao -lportaudio -lX11 -lXrandr -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lGLU -lGL -lCg -lCgGL -lcore -llzo2 -ldiscio -lbdisasm -linputcommon -lcommon -llua -lz -lsfml-network -lSDL Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::TransferByte(unsigned char&)': EXI_DeviceMic.cpp:(.text+0x3a4): undefined reference to `Pa_OpenDefaultStream' EXI_DeviceMic.cpp:(.text+0x487): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::~CEXIMic()': EXI_DeviceMic.cpp:(.text+0x4d6): undefined reference to `Pa_CloseStream' EXI_DeviceMic.cpp:(.text+0x4e5): undefined reference to `Pa_Terminate' EXI_DeviceMic.cpp:(.text+0x4f6): undefined reference to `Pa_GetErrorText' EXI_DeviceMic.cpp:(.text+0x53b): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::~CEXIMic()': EXI_DeviceMic.cpp:(.text+0x586): undefined reference to `Pa_CloseStream' EXI_DeviceMic.cpp:(.text+0x595): undefined reference to `Pa_Terminate' EXI_DeviceMic.cpp:(.text+0x5a6): undefined reference to `Pa_GetErrorText' EXI_DeviceMic.cpp:(.text+0x5eb): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::~CEXIMic()': EXI_DeviceMic.cpp:(.text+0x636): undefined reference to `Pa_CloseStream' EXI_DeviceMic.cpp:(.text+0x645): undefined reference to `Pa_Terminate' EXI_DeviceMic.cpp:(.text+0x656): undefined reference to `Pa_GetErrorText' EXI_DeviceMic.cpp:(.text+0x6a3): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::CEXIMic(int)': EXI_DeviceMic.cpp:(.text+0x762): undefined reference to `Pa_Initialize' EXI_DeviceMic.cpp:(.text+0x77b): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `CEXIMic::CEXIMic(int)': EXI_DeviceMic.cpp:(.text+0x802): undefined reference to `Pa_Initialize' EXI_DeviceMic.cpp:(.text+0x81b): undefined reference to `Pa_GetErrorText' Build/Linux-x86_64-release/libs/libcore.a(EXI_DeviceMic.o): In function `SetMic(bool)': EXI_DeviceMic.cpp:(.text+0x6f8): undefined reference to `Pa_StopStream' EXI_DeviceMic.cpp:(.text+0x708): undefined reference to `Pa_StartStream' collect2: ld returned 1 exit status scons: *** [/var/tmp/portage/games-emulation/dolphin-emu-9999-r8/image/usr/games/bin/dolphin-emu] Error 1 scons: building terminated because of errors. Patches, hacks and workarounds ?
Great news: upstream fixed the --as-needed linking issue, and as of r6258 Dolphin builds, links, and runs perfectly, even against a freshly merged wxGTK-2.8.10 (tested with my -r8 ebuild). Here are the details for anyone interested: http://code.google.com/p/dolphin-emu/source/detail?r=6258 I'm attaching an updated -r8 ebuild that simply removes the sed line implementing Carles' suggested fix. The upstream patch does essentially the same thing (though it's more thorough), so this is no longer needed. All other functionality is the same, which is why I'm leaving it at -r8. As for the reported portaudio and pulseaudio problems, I'm afraid I don't use either of them, so I can't offer much in the way of suggestions. The issue Rick described seems to be related to linking, so maybe it'll just work now? And Dolphin doesn't seem to offer a config option for pulseaudio; it looks like it enables support if you have it, and ignores it if you don't. Is there anything that specifically needs to be done to "support" it? Maybe just add a conditional dependency?
Created attachment 249908 [details] games-emulation/dolphin-emu-9999-r8.ebuild
(In reply to comment #70) > Is there > anything that specifically needs to be done to "support" it? Maybe just add a > conditional dependency? i pretty sure that's only thing can be done until switch is implemented by upstream.
Comment on attachment 249198 [details, diff] Patch to solve the --as-needed linking breakage Thanks for your ebuild, Jared. I'm marking mine obsolete. I agree with Sergei, let's wait for the new build system.
I'm attaching my last revision. As of r6276, bluetooth is no longer required to compile, so I've added a bluetooth USE flag to control this. I also added a pulseaudio USE flag. As discussed previously, both of these simply pull in the required dependencies if enabled; scons automatically enables/disables support depending on their presence, so no compile options are required. With this, I'm personally calling it done. I think it supports all the options we need, installs in the appropriate location, properly supports multiuser configuration (~/.dolphin-emu), and compiles cleanly on a currently Gentoo system. Bluetooth was pretty much my last annoyance, and they took care of that problem last night. I guess the LDFLAGS thing is still an issue for some, but as I (apparently) don't use that feature of portage, it hasn't affected me. Anyway, just wanted to post my update and final thoughts. Thanks to everyone for helping to pull this together. I think it's pretty damn solid now, and am looking forward to seeing it in portage one day.
Created attachment 250501 [details] games-emulation/dolphin-emu-9999-r9.ebuild
(In reply to comment #75) > Created an attachment (id=250501) [details] > games-emulation/dolphin-emu-9999-r9.ebuild > with this ebuild and current revision installed dolphin can't find its plugins on amd64 ebuild installs them into /usr/games/lib64/dolphin/ while dolphin looks into /usr/games/lib64/dolphin-emu/
(In reply to comment #76) > with this ebuild and current revision installed dolphin can't find its plugins > on amd64 > ebuild installs them into /usr/games/lib64/dolphin/ while dolphin looks into > /usr/games/lib64/dolphin-emu/ Did you name the ebuild dolphin-emu? or did you use the old name of just dolphin? The ebuilds I submitted expect to be called dolphin-emu (for reasons described in comment 46), and will fail if you rename it back to dolphin. What you describe seems to indicate this is the problem.
> Did you name the ebuild dolphin-emu? indeed, i accidentally made it dolphin instead of dolphin-emu
my gcc-4.3.2-r3 seems to struggle with -Wno-unused-result, which makes scons fail. here's a patch that made it to actual compilation. Index: SConstruct =================================================================== --- SConstruct (revision 6314) +++ SConstruct (working copy) @@ -92,7 +92,7 @@ if env['CCVERSION'] < '4.2.0': env['CCFLAGS'] += ['-Wno-pragmas'] if env['CCVERSION'] >= '4.3.0': - env['CCFLAGS'] += ['-Wno-array-bounds', '-Wno-unused-result'] + env['CCFLAGS'] += ['-Wno-array-bounds'] env['CPPDEFINES'] = [] if env['flavor'] == 'debug':
also had to upgrade my wxGTK-2.8.9 -> 2.8.10, otherwise compilation fails with error: 'wxAUI_MGR_LIVE_RESIZE' was not declared in this scope looks like http://code.google.com/p/dolphin-emu/issues/detail?id=1361
Jared, svn ebuild does not work for current revisions
Yeah, I noticed that the other night. I'm working on an updated ebuild to use cmake, which has recently been added to Dolphin (and is still being refined), so I want to hold off on posting an updated ebuild until I have that working. I'm also going to switch to Rick's approach of specifying the revision number so that the ebuild should always continue to work, regardless of which changes are made after that revision. In the meantime, I think you just need to make two changes to the -r9 ebuild to get it to build with scons. First, change line 46 as follows: -e "s;env\['prefix'\] + '/lib/;'$(games_get_libdir)/;" \ Second, comment out the opencl condition on line 57 (this is now automatically detected). I'm pretty sure that's all I needed to change to get a fresh build. If you still have trouble, please let me know. I'm hoping to have the cmake ebuild completed next week. Just won't have any more time to work on it until then.
(In reply to comment #82) > -e "s;env\['prefix'\] + '/lib/;'$(games_get_libdir)/;" \ Works for me without changing this. > Second, comment out the opencl condition on line 57 (this is now automatically > detected). Yes, that is neccessary. > If you still have trouble, please let me know. With portaudio useflag enabled the emerge stops (similar to bug 286866 ): >>> Emerging (2 of 2) games-emulation/dolphin-emu-9999-r9 from own * Package: games-emulation/dolphin-emu-9999-r9 * Repository: own * USE: amd64 bluetooth elibc_glibc kernel_linux multilib openal portaudio pulseaudio userland_GNU wxwidgets >>> Unpacking source... * subversion update start --> * repository: http://dolphin-emu.googlecode.com/svn/trunk Hole externen Verweis nach »Data/User/GameConfig« Externer Verweis, Revision 251. Hole externen Verweis nach »Data/User/Shaders« Externer Verweis, Revision 30. Revision 6385. * working copy: /usr/portage/distfiles/svn-src/dolphin-emu-read-only/trunk >>> Source unpacked in /var/tmp/portage/games-emulation/dolphin-emu-9999-r9/work >>> Preparing source in /var/tmp/portage/games-emulation/dolphin-emu-9999-r9/work/dolphin-emu-9999 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/games-emulation/dolphin-emu-9999-r9/work/dolphin-emu-9999 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/games-emulation/dolphin-emu-9999-r9/work/dolphin-emu-9999 ... scons: Reading SConscript files ... Checking for pkg-config version > 0.15.0... yes Checking for GLEW... (cached) Using pkg-config for glew... yes Checking for SDL... (cached) Using pkg-config for sdl... yes Checking for z... (cached) Using pkg-config for z... no Looking for lib z... yes Checking for lzo2... (cached) Using pkg-config for lzo2... no Looking for lib lzo2... yes Shared library soil not detected, falling back to the static library Shared library sfml not detected, falling back to the static library Checking for wxWidgets >= 2.8... (cached) yes Checking for bluez... (cached) Using pkg-config for bluez... yes Checking for alsa... (cached) Using pkg-config for alsa... yes Checking for ao... (cached) Using pkg-config for ao... yes Checking for openal... (cached) Using pkg-config for openal... yes Checking for portaudio... (cached) Using pkg-config for portaudio... no Looking for lib portaudio... yes ACCESS DENIED open_wr: /dev/snd/controlC0
BTW if you have suggestions/requests/bug reports about the new cmake build system now it's the time to make them. We want to make sure everything is working well on linux so dolphin can be properly packaged.
> With portaudio useflag enabled the emerge stops (similar to bug 286866 ): I just found a workaround: http://forums.gentoo.org/viewtopic-t-797680-start-0.html try SANDBOX_WRITE="/dev/snd" emerge dolphin-emu For the mplayer (bug 286866) fixing the configure script solved the problem (see comment 37 in bug 286866). In 286866 are other workarounds, too.
i was found it working after some work but it was only working with vanilla-gcc on hardened system. any other profile was _not_ working even with append-cflags -fnopic -fno-stack-protector-all -fno-stack-protector (was got it from hardened gentoo page).
am I doing something wrong? scons: Reading SConscript files ... Unknown variables: ['opencl'] the build stops here
(In reply to comment #87) This was discussed in comment 82 and comment 83. Please review for details.
Created attachment 254699 [details] cmake WIP ebuild I'm working on a cmake version of the ebuild, but I've hit a wall and could use some help. I (think) I have all of the configure bits taken care of, but compiling with make fails. The reason seems to be this, taken from the cmake output: -- <<< Gentoo configuration >>> Build type Gentoo Install path /tmp/portage/games-emulation/dolphin-emu-9999_p6430/work/dolphin-emu-9999_p6430_build/"/usr/games" Compiler flags: C -march=core2 -O2 -pipe C++ -march=core2 -O2 -pipe ;-fvisibility-inlines-hidden -pthread Notice that semi-colon in the C++ flags. I don't know exactly what's going on, but it appears that make is somehow taking that to be the name of the C++ compilter. The build fails with this /bin/sh: -fvisibility-inlines-hidden: command not found This only happens when I try to build through portage. If I do a direct build with cmake ... && make, it'll compile just fine. I've poked around quite a bit, but right now I'm stumped. I know that "-march=core2 -O2 -pipe" are my personal CXXFLAGS and "-fvisibility-inlines-hidden -pthread" is being set by dolphin, but I have no idea where, why it's being done in such a funky manner, nor (obviously) how to fix it. Any suggestions? Note: remove "-broken" from the filename before trying to use this ebuild.
(In reply to comment #89) It appears this may be an upstream bug: http://code.google.com/p/dolphin-emu/issues/detail?id=3507 I'll keep an eye on it and test again once it's been resolved.
Created attachment 254783 [details] games-emulation/dolphin-emu-9999_p6441.ebuild I've been able to get a working ebuild using cmake. In addition to switching to cmake, this ebuild includes an updated list of dependencies taken from the Dolphin Linux build wiki (with certain options forced on where appropriate), and, as you can see by the filename, is tied to a specific revision of Dolphin. I've done some limited testing and everything seems to work, but it could certainly use some more extensive testing, particularly with different combinations of USE flags. I'd appreciate any feedback. I'm also deprecating my scons ebuild at this time because it doesn't work with the current revision of Dolphin. The original scons configuration and build commands are commented out in the ebuild, though, so this can be reenabled if desired.
oh, damn it, now i have "undefined reference to `wx<something>'" errors too :( with latest cmake ebuild that is. before that cc1plus also gives warning that "-Wno-unused-result" is "incorrect key" gcc-4.4.5, glibc-2.12.1-r3, cmake-2.8.1-r2, binutils-2.20.1-r1
(In reply to comment #92) I've always received the no-unused-result warnings, even with the scons build. I don't recall seeing anything about an incorrect key or those undefined reference errors, though. Can you paste the actual error output? Also, which version of WX are you running?
the cc1plus error is in russian and it says "incorrect key: -Wno-unused-result"... in russian :) it's my backward translation of russian translated error since i'm too lazy right now to do it in different locale and portage doesn't eat 'LANG' variable directly. no matter, looks like it just small fuck up from developers - putting nonexistent compiler key to building options. we have a bigger ones. like this thing with wx. my wxGTK is 2.9.1, as i already stated before
Created attachment 254887 [details] 'undefined reference'-ridden build log from cmake ebuild
(In reply to comment #94) OK, this appears to be due to wxGTK-2.9.1. I tried upgrading my box and I get the same error. If you can downgrade to wxGTK-2.8.10 it should work. Otherwise, I filed a bug report with upstream: http://code.google.com/p/dolphin-emu/issues/detail?id=3529
Per upstream, the 2.9 development branch of wxwidgets is not supported and they don't currently plan on adding support. So, to "fix" this in the ebuild, change: >=x11-libs/wxGTK-2.8 to: x11-libs/wxGTK:2.8 Not ideal, but it should work. Has anyone else had a chance to test the new cmake ebuild?
are they fucking kidding ? 1) "development _branch_" reside in svn. this is damn release. official damn release. 2) i have working dolphin-emu built against wxGTK 2.9.1 in my system RIGHT NOW (while writing it). it's build with previous scons ebuild, as i also already stated. here: (8:28:24) [ ~ ] % ldd /usr/games/bin/dolphin-emu|grep wx libwx_gtk2u_aui-2.9.so.1 => /usr/lib/libwx_gtk2u_aui-2.9.so.1 (0x00007fad4ea05000) libwx_gtk2u_adv-2.9.so.1 => /usr/lib/libwx_gtk2u_adv-2.9.so.1 (0x00007fad4e69e000) libwx_gtk2u_core-2.9.so.1 => /usr/lib/libwx_gtk2u_core-2.9.so.1 (0x00007fad4dfc2000) libwx_baseu-2.9.so.1 => /usr/lib/libwx_baseu-2.9.so.1 (0x00007fad4dbdf000) (8:28:28) [ ~ ] % equery b /usr/lib/libwx_gtk2u_aui-2.9.so.1 * Searching for /usr/lib/libwx_gtk2u_aui-2.9.so.1 ... x11-libs/wxGTK-2.9.1 (/usr/lib64/libwx_gtk2u_aui-2.9.so.1.0.0) "we don't update, so you, frequently-updating-linux-assholes, don't update too" what i lame excuse to not fix their new, not properly set, build system. it most likely just don't pass some necessary linking flag... 3) after pondering few minutes about what i wrote above i made `LDFLAGS="-lwx_gtk2u_aui-2.9 -lwx_gtk2u_adv-2.9 -lwx_gtk2u_core-2.9 -lwx_baseu-2.9" emerge -v1 dolphin-emu` ...guess what ? IT BUILT! it probably don't need to link so many shit into plugins but it's working. please, politely advise 'man cmake' and reading documentation of shit they use for their development to them, because i can't. what a fucking joke.
(In reply to comment #98) > are they fucking kidding ? > > 1) "development _branch_" reside in svn. this is damn release. official damn > release. > 2) i have working dolphin-emu built against wxGTK 2.9.1 in my system RIGHT NOW > (while writing it). it's build with previous scons ebuild, as i also already > stated. > here: > (8:28:24) [ ~ ] % ldd /usr/games/bin/dolphin-emu|grep wx > libwx_gtk2u_aui-2.9.so.1 => /usr/lib/libwx_gtk2u_aui-2.9.so.1 > (0x00007fad4ea05000) > libwx_gtk2u_adv-2.9.so.1 => /usr/lib/libwx_gtk2u_adv-2.9.so.1 > (0x00007fad4e69e000) > libwx_gtk2u_core-2.9.so.1 => /usr/lib/libwx_gtk2u_core-2.9.so.1 > (0x00007fad4dfc2000) > libwx_baseu-2.9.so.1 => /usr/lib/libwx_baseu-2.9.so.1 > (0x00007fad4dbdf000) > (8:28:28) [ ~ ] % equery b /usr/lib/libwx_gtk2u_aui-2.9.so.1 > * Searching for /usr/lib/libwx_gtk2u_aui-2.9.so.1 ... > x11-libs/wxGTK-2.9.1 (/usr/lib64/libwx_gtk2u_aui-2.9.so.1.0.0) > > "we don't update, so you, frequently-updating-linux-assholes, don't update too" > what i lame excuse to not fix their new, not properly set, build system. it > most likely just don't pass some necessary linking flag... > > 3) after pondering few minutes about what i wrote above i made > `LDFLAGS="-lwx_gtk2u_aui-2.9 -lwx_gtk2u_adv-2.9 -lwx_gtk2u_core-2.9 > -lwx_baseu-2.9" emerge -v1 dolphin-emu` > ...guess what ? IT BUILT! > it probably don't need to link so many shit into plugins but it's working. > please, politely advise 'man cmake' and reading documentation of shit they use > for their development to them, because i can't. what a fucking joke. > I had no idea gentoo allows language like that in their bug reports. The right thing to do is to submit a bug report with a patch. The wrong thing to do is to use foul language to insult the developers who took the time to rewrite the build system.
I quite agree. Officially, it's against CoC http://www.gentoo.org/proj/en/council/coc.xml
and still it's more relevant to the issue than any of that. one thing if developers can't do something or postpone it because of priority consideration, the other if they acknowledge _and_ outright refuse to deal with it. especially if it's one of the issues the whole thing was started about (wx & pulse linking problems, remember any of that ?) which makes it entirely pointless. i woken up today and this was almost the first thing i saw which pissed me off beyond believe and i apologize to developers but otherwise take responsibility for every word. if you have any more morality issues, you know where to find my email to discuss it.
(In reply to comment #97) > Per upstream, the 2.9 development branch of wxwidgets is not supported and they > don't currently plan on adding support. So, to "fix" this in the ebuild, > change: > >=x11-libs/wxGTK-2.8 > > to: > x11-libs/wxGTK:2.8 > > Not ideal, but it should work. > > Has anyone else had a chance to test the new cmake ebuild? > Your ebuild seems to work for me. Thanks! As a side note, don't try to build any revision newer than r6446, as it is broken due to a gentoo kernel-headers patch. I just asked in the #gentoo-kernel but have no answer so far. The patch in question prevents the linux/time.h header from being included.
Created attachment 255063 [details] games-emulation/dolphin-emu-9999_p6446.ebuild Updated ebuild: * bumped to r6446 (not going higher per Carles' recommendation) * wxGTK 2.8 enforced - will link against 2.8 even if 2.9 is installed * cleaned up ebuild dependencies and testing code * still leaving scons config stuff commented out for now FYI, some more recent discussion from upstream indicates that they may be willing to support wxGTK 2.9. I provided LDFLAGS setting Sergey posted (and confirmed that it works on my system as well), so we'll see how that goes. In the meantime, since 2.8 is the official stable version supported by both Gentoo and Dolphin, I'd prefer to leave the 2.8 restriction in place. Carles, thanks for the report. I've been very busy testing Dolphin over the past couple of days myself ;-), so between my experience and your confirmation I'll call this good.
Hi! The new ebuild is failing with this output In file included from /usr/include/wx-2.9/wx/platform.h:711, from /usr/include/wx-2.9/wx/defs.h:26, from /usr/include/wx-2.9/wx/wx.h:15, from /var/tmp/portage/games-emulation/dolphin-emu-9999_p6446/work/dolphin-emu-9999_p6446/Source/Core/DebuggerUICommon/Src/DebuggerUIUtil.h:21, from /var/tmp/portage/games-emulation/dolphin-emu-9999_p6446/work/dolphin-emu-9999_p6446/Source/Core/DebuggerUICommon/Src/DebuggerUIUtil.cpp:19: /usr/include/wx-2.9/wx/chkconf.h:94:9: error: #error "wxUSE_ANY must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:126:9: error: #error "wxUSE_FILE_HISTORY must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:158:9: error: #error "wxUSE_FSWATCHER must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:750:9: error: #error "wxUSE_INFOBAR must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:918:9: error: #error "wxUSE_RIBBON must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:1078:9: error: #error "wxUSE_UIACTIONSIMULATOR must be defined, please read comment near the top of this file." /usr/include/wx-2.9/wx/chkconf.h:1818:14: error: #error "DocView requires wxUSE_FILE_HISTORY" BTW, I've made a small patch to fix the -Wno-unused-result warning for gcc 4.4.5
(In reply to comment #104) > Hi! The new ebuild is failing with this output That's odd, for a couple reasons: 1. Out of all the error messages I've seen up to this point, that's a new one 2. It looks like it's trying to link against wxGTK 2.9, which shouldn't be done with the latest ebuild. Are you using dolphin-emu-9999_p6446.ebuild? If so, did you make any changes? > BTW, I've made a small patch to fix the -Wno-unused-result warning for gcc > 4.4.5 Cool, care to share? Those warnings have been annoying me for some time, but I haven't gotten around to filing a bug report upstream yet. Providing a patch would make it much more likely to get fixed.
Created attachment 255141 [details, diff] Patch to get rid of cc1plus: warning -Wno-unused-result message Additionally I've put a conditional CXX_VERSION=`gcc-fullversion` ... if [ "$CXX_VERSION" = "4.4.5" ]; then epatch $PATCHES fi cmake-utils_src_configure }
(In reply to comment #105) > (In reply to comment #104) > > Hi! The new ebuild is failing with this output > > That's odd, for a couple reasons: > > 1. Out of all the error messages I've seen up to this point, that's a new one > > 2. It looks like it's trying to link against wxGTK 2.9, which shouldn't be done > with the latest ebuild. > > Are you using dolphin-emu-9999_p6446.ebuild? If so, did you make any changes? > > > BTW, I've made a small patch to fix the -Wno-unused-result warning for gcc > > 4.4.5 > > Cool, care to share? Those warnings have been annoying me for some time, but I > haven't gotten around to filing a bug report upstream yet. Providing a patch > would make it much more likely to get fixed. > (In reply to comment #105) > (In reply to comment #104) > > Hi! The new ebuild is failing with this output > > That's odd, for a couple reasons: > > 1. Out of all the error messages I've seen up to this point, that's a new one > > 2. It looks like it's trying to link against wxGTK 2.9, which shouldn't be done > with the latest ebuild. > > Are you using dolphin-emu-9999_p6446.ebuild? If so, did you make any changes? > > > BTW, I've made a small patch to fix the -Wno-unused-result warning for gcc > > 4.4.5 > > Cool, care to share? Those warnings have been annoying me for some time, but I > haven't gotten around to filing a bug report upstream yet. Providing a patch > would make it much more likely to get fixed. > The only change I've made is: --- dolphin-emu-9999_p6446.ebuild 2010-11-22 19:59:26.000000000 -0200 +++ /usr/local/portage/games-emulation/dolphin-emu/dolphin-emu-9999_p6446.ebuild2010-11-22 19:48:20.000000000 -0200 @@ -42,6 +42,8 @@ dev-util/pkgconfig media-gfx/nvidia-cg-toolkit" #dev-util/scons +CXX_VERSION=`gcc-fullversion` +PATCHES="${FILESDIR}/Wno_unused_result.patch" # Configure using scons (deprecated) #src_prepare() { @@ -63,6 +65,10 @@ -Dplugindir=$(games_get_libdir)/${PN} $(cmake-utils_use !wxwidgets DISABLE_WX) $(cmake-utils_use encode ENCODE_FRAMEDUMPS)" + + if [ "$CXX_VERSION" = "4.4.5" ]; then + epatch $PATCHES + fi cmake-utils_src_configure }
Ok, bad news is that I didn't manage to get any info. from the devs. on why this 00_all_0008-HACK-linux-pull-in-C-library-headers patch is being applied. I addressed vapier directly but the only answer I got was: "upgrade". From what I saw, neither upgrading linux-headers nor glibc would address the situation, so I'm not sure what he meant. The good news is that the patch causing this failure was reverted upstream (see r6454 comments for details), so dolphin-emu is building again with latest revisions. As a side note, I think the "incorrect key: -Wno-unused-result" warning was also fixed upstream.
Yeah, that (obviously) shouldn't matter. Out of curiosity, what does "wx-config --version" report? If it's 2.9.1, can you try switching to to 2.8.10 (eselect wxwidgets set 2, or something like that) and see if dolphin will build with that? Also, thanks for the patch. Does that warning appear ONLY with 4.4.5, and not 4.4.4 or earlier?
(In reply to comment #108) Sweet. Thanks for the heads up, Carles.
(In reply to comment #109) > Yeah, that (obviously) shouldn't matter. > > Out of curiosity, what does "wx-config --version" report? If it's 2.9.1, can > you try switching to to 2.8.10 (eselect wxwidgets set 2, or something like > that) and see if dolphin will build with that? > > Also, thanks for the patch. Does that warning appear ONLY with 4.4.5, and not > 4.4.4 or earlier? > Well I didn't try with gcc 4.4.4 but if [ "$CXX_VERSION" > "4.4.3" ]; then ... Should do the trick.. Btw, my wx-config --version outputs 2.8.10 but something seems to be messed up with my installation here, after I unmerge wxGTK-2.9 I got much less error output
A quick question: dolphin-emu depends on nvidia-cg-toolkit; nvidia-cg-toolkit depends on virtual/glut; virtual/glut is not in portage anymore, probably because glut is slated for removal and freeglut is now the only available implementation (the virtual could have been left in portage IMO, but it hasn't). Does dolphin-emu need to depend on the Nvidia toolkit, even on ATI/AMD platforms? IIRC, it does. So, considering the toolkit ebuild depended on a virtual package, it is safe to assume that in the end dolphin will work with freeglut and modify the nvidia-cg-toolkit accordingly? From a portage point of view, it seems so, but I haven't been able to test the actual application yet.
(In reply to comment #112) nvidia-cg-toolkit is definitely required for building, regardless of the video card/driver in use. Trust me, I tried. :-) The glut thing is news to me, but I just checked the nvidia-cg-tookit ebuild and it looks like it's already been updated to point to freeglut rather than virtual/glut. I think you should be able to just re-emerge nvidia-cg-toolkit and then rebuild dolphin to confirm that it will work with freglut. At that point, I guess you could also remove virtual/glut if nothing else depends on it. By the way, I was hoping to test out the stuff that Bruno and Carles mentioned yesterday, but I didn't get the chance last night, and I'll be heading out of town shortly, so things will be quiet from me for a few days (to the relief of many on the CC list, I'm sure :-). I'll resume working on this again when I get back.
(In reply to comment #113) > (In reply to comment #112) > nvidia-cg-toolkit is definitely required for building, regardless of the video > card/driver in use. Trust me, I tried. :-) I do. :) > The glut thing is news to me, but I just checked the nvidia-cg-tookit ebuild > and it looks like it's already been updated to point to freeglut rather than > virtual/glut. [...] This is my fault, sorry. I had put the toolkit ebuild from this bug in my local portage overlay with a 0017-r1 suffix, so I never got to notice that the 0017 ebuild in portage has been updated to depend on freeglut. To sum things up, forget my post. :]
Sorry if I'm posting yet again... I now remembered (by trial) why I had an nvidia-cg-toolkit in my local portage overlay. When the one from portage is installed, dolphin-emu fails to build, finding an error in the configure process (because of wrong paths, it seems). AMD64 system here. CMake Error at CMakeTests/CheckLib.cmake:28 (message): Cg is required but not found Am I the only one encountering this error? (In reply to comment #114) > (In reply to comment #113) > > (In reply to comment #112) > > The glut thing is news to me, but I just checked the nvidia-cg-tookit ebuild > > and it looks like it's already been updated to point to freeglut rather than > > virtual/glut. [...] > > This is my fault, sorry. I had put the toolkit ebuild from this bug in my local > portage overlay with a 0017-r1 suffix, so I never got to notice that the 0017 > ebuild in portage has been updated to depend on freeglut. > > To sum things up, forget my post. :] >
(In reply to comment #115) Since 2.1.0016 nvidia-cg-toolkit installs into /opt. The CMake looks into /usr, so it doesn't find it. Either downgrade to 0012 or patch the build system :)
Well, I ended up putting the toolkit ebuild from this bug back in my overlay, editing the glut/freeglut part. (In reply to comment #116) > (In reply to comment #115) > Since 2.1.0016 nvidia-cg-toolkit installs into /opt. The CMake looks into /usr, > so it doesn't find it. Either downgrade to 0012 or patch the build system :) >
(In reply to comment #117) > Well, I ended up putting the toolkit ebuild from this bug back in my overlay, > editing the glut/freeglut part. yep, i thought too that it would be better option for now :) but real fix will be for developers to add option to define installation path for it (CG is a blob and /opt is right place for it by that logic). i hope all building issues will be addressed for the next release, which does not happening any time soon, i think (and only after good, buildable release it will be feasible to add it to portage, i guess). maybe they even could make cg optional by that time and make some love with mesa glsl compiler (or what is OSS option for that purpose can be). and it looks like '-Wno-unused-result' is gcc >4.5 option (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c24), so checking if version is LESS than 4.5 would be correct. real fix, again, is for cmake to check that.
(In reply to comment #115) > Sorry if I'm posting yet again... I now remembered (by trial) why I had an > nvidia-cg-toolkit in my local portage overlay. When the one from portage is > installed, dolphin-emu fails to build, finding an error in the configure > process (because of wrong paths, it seems). AMD64 system here. > > CMake Error at CMakeTests/CheckLib.cmake:28 (message): > Cg is required but not found I worked around this with ln -s /opt/nvidia-cg-toolkit/lib/libCg.so /usr/local/lib/libCg.so ln -s /opt/nvidia-cg-toolkit/lib/libCgGL.so /usr/local/lib/libCgGL.so ln -s /opt/nvidia-cg-toolkit/include/Cg/ /usr/include/Cg Maybe the ebuild can do this, but this is a dirty hack... I use nvidia-cg-toolkit-2.2.0004 (own ebuild with freeglut dep), and the p6446 compiled fine (I have not started dolphin yet).
Whenever possible, I prefer an ebuild overlay rather than leaving symlinks around... but your hack, while dirty should work. Like Sergey said, the clean solution would be to be able to tell dolphin where to look for those libraries. (In reply to comment #119) > I worked around this with > ln -s /opt/nvidia-cg-toolkit/lib/libCg.so /usr/local/lib/libCg.so > ln -s /opt/nvidia-cg-toolkit/lib/libCgGL.so /usr/local/lib/libCgGL.so > ln -s /opt/nvidia-cg-toolkit/include/Cg/ /usr/include/Cg > > Maybe the ebuild can do this, but this is a dirty hack... > > I use nvidia-cg-toolkit-2.2.0004 (own ebuild with freeglut dep), and the p6446 > compiled fine (I have not started dolphin yet). >
Created attachment 261660 [details] dolphin-emu r7093 ebuild with hardened fixed This ebuild appends -fno-pie and filters -flto and -fwhole-program. It also adds appropriate PaX markings.
(In reply to comment #121) > This ebuild appends -fno-pie and filters -flto and -fwhole-program. Where do those flags come from? I haven't seen them mentioned in any documentation related to dolphin. I'd like to know how they help/hurt performance. Thanks.
(In reply to comment #122) > (In reply to comment #121) > > This ebuild appends -fno-pie and filters -flto and -fwhole-program. > > Where do those flags come from? I haven't seen them mentioned in any > documentation related to dolphin. I'd like to know how they help/hurt > performance. > > Thanks. Those flags come from the gcc manual. The first (-fpie) would hurt performance by causing dolphin-emu to segfault. The second and third hurt performance by causing compilation to fail--visibility needs to be handled correctly for the former to function and more so for the latter to function, dolphin-emu doesn't handle visibility sufficiently for either to function. Note that the latter two are not hardened-related.
Created attachment 265243 [details] cmake 2.8.1 build fix I don't know which cmake version you guys use, but with 2.8.1 (and dolphin >= p7093) I get ################################ [ 90%] Building CXX object Source/Core/DebuggerWX/CMakeFiles/debwx.dir/Src/BreakpointWindow.cpp.o In Datei, eingefügt von /usr/include/gtk-2.0/gdk/gdkcairo.h:28, von /usr/include/gtk-2.0/gdk/gdk.h:33, von /usr/include/gtk-2.0/gtk/gtk.h:32, von /var/tmp/portage/games-emulation/dolphin-emu-9999_p7093/work/dolphin-emu-9999_p7093/Source/Core/DebuggerWX/Src/../../DolphinWX/Src/X11Utils.h:25, von /var/tmp/portage/games-emulation/dolphin-emu-9999_p7093/work/dolphin-emu-9999_p7093/Source/Core/DebuggerWX/Src/../../DolphinWX/Src/Frame.h:35, von /var/tmp/portage/games-emulation/dolphin-emu-9999_p7093/work/dolphin-emu-9999_p7093/Source/Core/DebuggerWX/Src/CodeWindow.h:32, von /var/tmp/portage/games-emulation/dolphin-emu-9999_p7093/work/dolphin-emu-9999_p7093/Source/Core/DebuggerWX/Src/BreakpointWindow.cpp:21: /usr/include/gtk-2.0/gdk/gdkpixbuf.h:37:35: Fehler: gdk-pixbuf/gdk-pixbuf.h: Datei oder Verzeichnis nicht gefunden ################################ For cmake 2.8.2 it seems that this bug is known, because there is a workaraound in CMakeLists.txt. To solve this problem you can 1) disable the wxwidget useflag (no gui) 2) add >=cmake-2.8.2 dependency in the ebuild and install newer cmake 3) try my patch attatched (it is against p7319), I use the same workaround as for 2.8.2. greetings Jan
Attaching ebuild for the Dolphin 3.0 release. It's very similar to my last build, just with two main differences: * Switched from subversion to git, as git is now preferred by upstream * Incorporated Mr. B's flag and pax suggestions Note that this is, unfortunately, still using a revision control system as upstream has not made a source tarball available for the 3.0 release. Official Linux installation instructions seem to be to pull from the Git repo using the 3.0 tag. That's a rather shitty approach, in my opinion, but it at least seems to work fine. Anyway, 3.0 builds and runs better than ever on my system, so this looks like a great release. Since this is now 'final', can it be considered for inclusion in portage?
Created attachment 284779 [details] games-emulation/dolphin-emu-3.0.ebuild
Created attachment 289187 [details] games-emulation/dolphin-emu/dolphin-emu-3.0.ebuild current sfml2 upstream has several API changes making the system check of dolphins CMakeLists.txt quiet useless (i.e. it doesn't build with current sfml upstream). As libsfml2-9999 is in gamerlay as a dependency for my game launcher typhon I added an ugly sed expression to the ebuild which disables the system check. I hope this will get fixed in dolphin upstream when sfml2 is "done". Thank you for the ebuild! adding it to gamerlay now :)
>>> Unpacking source... * git.eclass is deprecated. * Please update your ebuilds to use git-2 instead. For details, see * http://archives.gentoo.org/gentoo-dev/msg_b7ba363cae580845819ae3501fb157e9.xml
Btw, this doesn't build: /var/tmp/portage/games-emulation/dolphin-emu-3.0/work/dolphin-emu-3.0/Source/Core/Common/Src/CDUtils.cpp: In function 'bool is_cdrom(const char*, char*)': /var/tmp/portage/games-emulation/dolphin-emu-3.0/work/dolphin-emu-3.0/Source/Core/Common/Src/CDUtils.cpp:179:13: error: 'close' was not declared in this scope
The git message can be safely ignored for now. Yes, it should be updated, but since this isn't in the tree I don't see a need to bump the ebuild solely for that. As for the build error, I'm not able to reproduce it on my system. I'm running GCC 4.5.3, which is the current stable version in Gentoo. What version are you running?
I was using 4.7.1. I switched to 4.6.3, but with that version is fails differently: /var/tmp/portage/games-emulation/dolphin-emu-3.0/work/dolphin-emu-3.0/Source/Plugins/Plugin_VideoSoftware/Src/../../Plugin_VideoOGL/Src/GLUtil.h:117:19: fatal error: Cg/cg.h: No such file or directory
What version of nvidia-cg-toolkit do you have installed? Search through the comments for some info about this. If I recall correctly, the build scripts expect the cg headers to be installed in a certain place, or something like that. It should work fine with the Gentoo stable version, 2.1.0012, but if you're using something newer then that could explain the problem. FYI, I've only tested this against Gentoo stable, since that's what I run on my system, and I can say that I have had trouble in the past when moving to newer versions (which required some upstream fixes). YMMV, of course, but if you want to use Dolphin 3.0, I'd suggest sticking with the Gentoo stable versions of it's various dependencies. If you want to use more recent versions, you'll probably be better off trying one of the live ebuilds, though I haven't messed with any of those myself since 3.0 was released.
Created attachment 333390 [details] games-emulation/dolphin-emu/dolphin-emu-3.5.ebuild Some kind of updated ebuild for dolphin-emu 3.5. Build system is a mess, need to do a lot of work to test how it's works...
(In reply to comment #133) > Created attachment 333390 [details] > games-emulation/dolphin-emu/dolphin-emu-3.5.ebuild Thx for the ebuild. This version needs gcc-4.6 to compile, please include an according dependency. Besides this it works for me :-).
Created attachment 335972 [details] games-emulation/dolphin-emu/dolphin-emu-3.5.ebuild Try this one please.
The latest ebuild doesn`t work too, cause the links have changed. I`ve got it to work, when I changed the following lines to: SRC_URI="https://dolphin-emu.googlecode.com/files/dolphin-3.5-src.zip" src_unpack() { unpack "dolphin-3.5-src.zip" cd ${S} } and rename the ebuild to dolphin-emu-3.5.ebuild. I have no programming knowledge at all, so I hope that this would work for others too. Please confirm
With GCC 4.8 the building fails https://code.google.com/p/dolphin-emu/issues/detail?id=6198 I've adapted the patch as it won't apply cleanly and it now compiles.
Created attachment 347322 [details, diff] dolphin-emu-3.5-gcc-4.8.patch
(In reply to comment #138) > Created attachment 347322 [details, diff] [details, diff] > dolphin-emu-3.5-gcc-4.8.patch I maintain my own dolphin-3.5 ebuild on my github account, which is also a layman overlay by the name of twitch153. I added your patch and don't mind maintaining the dolphin ebuilds. :)
(In reply to comment #139) > I maintain my own dolphin-3.5 ebuild on my github account, which is also a > layman overlay by the name of twitch153. Just tried it out. It doesn't build: -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.8") Using shared zlib GLEW found Cg not found Using static Cg from Externals CgGL not found -- Found wxWidgets: TRUE Found wxWidgets version 2.8.12 At least 2.9.3 is required; ignoring found version -- Found Freetype: /usr/lib64/libfreetype.so (found version "2.4.11") -- Found GTK2_GTK: /usr/lib64/libgtk-x11-2.0.so Using static wxWidgets from Externals gthread-2.0 found pangocairo found CMake Error at CMakeLists.txt:554 (add_subdirectory): add_subdirectory given source "Externals/wxWidgets3" which is not an existing directory.
(In reply to comment #140) > (In reply to comment #139) > > Just tried it out. It doesn't build: > > -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.8") > Using shared zlib > GLEW found > Cg not found > Using static Cg from Externals > CgGL not found > -- Found wxWidgets: TRUE > Found wxWidgets version 2.8.12 > At least 2.9.3 is required; ignoring found version > -- Found Freetype: /usr/lib64/libfreetype.so (found version "2.4.11") > -- Found GTK2_GTK: /usr/lib64/libgtk-x11-2.0.so > Using static wxWidgets from Externals > gthread-2.0 found > pangocairo found > CMake Error at CMakeLists.txt:554 (add_subdirectory): > add_subdirectory given source "Externals/wxWidgets3" which is not an > existing directory. I know what the problem is. Currently the ebuild is deleting all bundled libraries so that it is using the ones built on your system. Can you do two things for me and paste the output?: 1.) equery which wxGTK 2.) eselect wxwidgets list What I think is going on particularly on your system is that the dolphin ebuild is pulling in wxGTK 2.9 but the wxwidgets is not set to the 2.9 one. :) We'll see. If that is the case then I need to find a way to set that in the ebuild. Please do let me know.
(In reply to comment #140) > Just tried it out. It doesn't build: > Never mind, that was the issue and I properly fixed it and pushed to the git repo. I also set the lzo USE flag to be set at all times. This is because currently without liblzo it won't build when I remove all of the bundled libraries. But, everything should be okay now. I'll also make the same changes to the 9999 ebuild for anyone who wants to use the lastest from their git tree. I'll push that out shortly.
Created attachment 348476 [details, diff] Use wxwidgets.eclass Ah, OK, I had no idea that I have to select the 2.9 version with eselect. I've done that now and it builds. I've looked into the eclasses of portage, and there's wxwidgets.eclass. Here's a patch (attached) against dolphin-3.5.ebuild that makes it use the eclass and automatically use the correct version of wxGTK for building.
Oops, I was still editing my reply and didn't see you already figured it out. One more note: most of the deps in RDEPEND don't really belong there. RDEPEND is for deps that are not required during building, but only during runtime. Stuff that's required for building should really be moved into DEPEND instead. And thanks for maintaining this ebuild :-)
(In reply to comment #144) > And thanks for maintaining this ebuild :-) I'll ditto this. Haven't been messing much with Dolphin since the 3.0 release, but it's really nice to still see some activity on this.
(In reply to comment #144) > Oops, I was still editing my reply and didn't see you already figured it out. > > One more note: most of the deps in RDEPEND don't really belong there. > RDEPEND is for deps that are not required during building, but only during > runtime. Stuff that's required for building should really be moved into > DEPEND instead. > > And thanks for maintaining this ebuild :-) Right, with this ebuild it's tough to decide what's a DEPEND and what an RDEPEND simply because of how cmake works. But yeah, I should probably move it to the DEPEND portion of the ebuild. And no problem! I use it too, so why not spread the love? It might be on the portage tree, eventually.
Alright then, everything should be good now. Let me know if you guys run into any more issues and I'll be happy to test and submit patches to the ebuild.
The live ebuild doesn't emerge: * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/games-emulation/dolphin/files/dolphin-emu-9999-gcc-4.8.patch * ( dolphin-emu-9999-gcc-4.8.patch ) Fixing the ebuild and using the correct filename also doesn't work, since the patch won't apply anymore. It should be noted that I'm using GCC 4.7. I do have 4.8 installed, but only for development. The gcc profile I have set with gcc-config is 4.7.3. So I removed the patch completely, but then it fails because it can't find the soundtouch library. After I installed it manually (media-libs/libsoundtouch) it builds (and runs) correctly. So I suppose the patch needs to go and "media-libs/libsoundtouch" has to be added to DEPEND.
(In reply to comment #148) > The live ebuild doesn't emerge: > > * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: > * > * > /usr/local/portage/games-emulation/dolphin/files/dolphin-emu-9999-gcc-4.8. > patch > * ( dolphin-emu-9999-gcc-4.8.patch ) > > Fixing the ebuild and using the correct filename also doesn't work, since > the patch won't apply anymore. > > It should be noted that I'm using GCC 4.7. I do have 4.8 installed, but only > for development. The gcc profile I have set with gcc-config is 4.7.3. > > So I removed the patch completely, but then it fails because it can't find > the soundtouch library. After I installed it manually > (media-libs/libsoundtouch) it builds (and runs) correctly. > > So I suppose the patch needs to go and "media-libs/libsoundtouch" has to be > added to DEPEND. The patch issue is well, a screwup on my part because I have it looking for dolphin-emu-9999-gcc-4.8.patch I screwed up on that one haha But yeah, if it wouldn't install without libsoundtouch then that is a new dependency that they recently added. So that's a good find. Now that I'm starting to think about it, I don't think this particular live ebuild should have any patching done to it at all. Since, you know, they are meant for development purposes anyways. I think it'd be best to remove the patching but keep the deletion of bundled libraries. This can help us figure out when they add new dependencies. I'll fix the ebuild and push to the repo in a few minutes. :)
(In reply to comment #149) > > This can help us figure out when they add new dependencies. I'll fix the > ebuild and push to the repo in a few minutes. :) And done. Sync up and enjoy.
(In reply to comment #149) > I don't think this particular live ebuild should > have any patching done to it at all. Since, you know, they are meant for > development purposes anyways. I think it'd be best to remove the patching > but keep the deletion of bundled libraries. If it doesn't build, then a patch is of course needed. Otherwise there's no point in having the ebuild to begin with. In this case the patch doesn't apply though, so there's no point in keeping it.
(In reply to comment #151) > (In reply to comment #149) > > I don't think this particular live ebuild should > > have any patching done to it at all. Since, you know, they are meant for > > development purposes anyways. I think it'd be best to remove the patching > > but keep the deletion of bundled libraries. > > If it doesn't build, then a patch is of course needed. Otherwise there's no > point in having the ebuild to begin with. In this case the patch doesn't > apply though, so there's no point in keeping it. I don't disagree. But typically 9999 live ebuilds are used for developmental purposes. But, thinking of how the dolphin emulator team does handle their updates they usually do everything through git without releasing versioning tar balls like a lot of other developer teams would. So I think it would be smart to include patching if it's needed.
"net-libs/miniupnpc" needs to be added to DEPEND now, otherwise emerge fails.
Dolphin emulator was just put on the portage tree by myself. It's the same thing as in my layman overlay but from now on I will be maintaining it on there instead. Please continue to submit more bug reports against this if you run into any issues. Thank you guys!
Thanks Devan for getting this into the tree. First thing, please wildcard this in the ebuild: if has_version "=sys-devel/gcc-4.8.0"; then epatch "${FILESDIR}"/${PN}-emu-${PV}-gcc-4.8.patch fi as I'm using GCC 4.8.1, it obviously doesnt apply the patch. Second, you might want to rename some old references of "dolphin-emu" to "dolphin", such that you could use the above line simply as ${P}-gcc-4.8.patch etc.
Since Dolphin's in tree now, shouldn't this ticket be closed now in favor of new tickets for new issues?
Absolutely!
