Arch Linux User Repository

Has been fixed in 25c77babebe625b46d96d62af9ef3a7bb3f4d99c. The header curl.h is now included directly which should prevent further errors of this kind.

Seems to be broken again:

http://pastebin.com/0VNNuAh7

cURL version: 7.50.1-1

Downgraded cURL to version 7.50.0-1.

Compiles without the error.

Seems the problem lies in:

http://pastebin.com/YaqXcRTe (diff of /usr/include/curl/curl.h 7.50.0-1 to 7.50.1-1)

Ah my bad. For some reason I thought the package needed to be updated manually. Probably should have checked the PKGBUILD.

@Martchus: Great job.
@cubethethird: Why flag out of date?

Just finished building the latest master from github and it builds without issue. Also, due to a previous PR, my generic USB gamepad now works again. Yay!

The fix is merged now :-)

The problem occurs because our libcurl is newer than the one version used by the Dolphin devs. I have already fixed it, just need to test whether it actually works and then create a pull request.

Here is the PR: https://github.com/dolphin-emu/dolphin/pull/4066
To use it until it is merged (there is also an alternative fix which might be merged instead), just use my fork: https://github.com/Martchus/dolphin

I've got the same error too. Log is the same as @DrDoctor.

I'm having build problems when building utilsx11: http://pastebin.com/nUmN3HUT

Can't reproduce, probably fixed upstream.

Build error occurs when building Core.cpp.o. Full log of build: http://pastebin.com/gcdb17DU

@thejacer87 you should try doing a pacman -Syu, and if that fails, refreshing your mirrors file

error: failed retrieving file 'mbedtls-2.2.1-1-x86_64.pkg.tar.xz'

tries all the mirrors it can, then fails. this happens for dolphin-emu-git and dolphin-emu

You most likely built it on a system with sfml installed, and ran it on a system without sfml installed. Try rebuilding on the latter.

dolphin-emu: error while loading shared libraries: libsfml-network.so.2.3: cannot open shared object file: No such file or directory

Dolphin appears to require sfml in order to run, but it's no longer a dependency.

Updated to mirror [community]. FTR, 4.0.2 was hardcoded because there was no 4.0.2 tag, but it's all good now with 5.0 :)

The first part of the version should be updated to 5.0 (newly released). Also, if you really want to have the release or tag number in the version, shouldn't you get it directly from git, something like "git describe --abbrev=0 --tags"?

Hi, now that usage statistics reporting has been merged (see <https://dolphin-emu.org/blog/2016/06/19/optional-usage-statistics-reporting/>), you should add -DDISTRIBUTOR='aur.archlinux.org' to the cmake options so upstream can see where these builds comes from.

Also, you should install the udev rule for the Wii U GC adapter, add `install -Dm644 Data/51-usb-device.rules "$pkgdir/usr/lib/udev/rules.d/51-usb-device.rules"` to the package_dolphin-emu-git function.

is there any reason performance or stability wise, to compile with clang?

Dolphin-emu is still super slow with the new Nvidia driver 364.16 (it was all good months ago).
Does anyone know why? Is there a solution?
Because now, sadly, I have to run dolphin on Windows if I want to play :(

I'm also using NVIDIA and noticed that the performance is very impaired in some cases. I don't know since when exactly, because I'm not playing regularly.

I switched from the regular package to this Git version and it actually helped. However, I am still using the version which has pie enabled because I accidentally used an older version of the PKGBUILD. Because this is working for me, I'm currently not rebuilding.

Additionally, the compositor seems to have a big impact on the performance. Under Plasma 5 with KWin I just get around 20 FPS playing Wind Waker with the best settings. Disabling the compositor doesn't help (alt + shift + F12) and just causes the Plasma shell to stop updating so the Plasma shell is more or less unusable. However, when starting a plain Open Box session, I can play with the same setup with almost 60 FPS. This is also the case when playing other games without emulation, e.g. Talos Principle.

But Dolphin is always using 2 cores for me.

@Neros: You're not the only one. I literally just bought a Gamecube to USB adapter to play Metroid Prime and I tried the game again and it's running much slower than it did a month ago. I tried reverting to nvidia-352 but it ran the same. I even tried an older kernel and that didn't help. I'm not quite sure how to fix this, but one thing I noticed is that dolphin is only using one CPU thread, when it should be using 2. Does anyone have any ideas on what this could be or how to fix it?

It seems that dolphin doesn't work good with the last nvidia driver 361.28. All the games are as slow as if I was using the Intel card...
Am I the only one?

Thanks for the reply. Seems I accidentally used an old version of the PKGBUILD.

I also read the comment from the Dolphin dev about the pie flag. Seems I'm luckily not immediately affected by the bug.

That the Qt GUI is currently broken is not a big deal since there haven't been a lot of features implemented yet.

Martchus:
Those changes appear to already be in the PKGBUILD.

However, DolphinQt2 is broken in the latest PKGBUILD as -fno-pie is enabled.
Qt requires pie and we are waiting on a pull request that ensures the -fno-pie flag is not applied to it.
https://github.com/dolphin-emu/dolphin/pull/3612/files

Dolphin devs seem to call the Qt GUI now Qt2.

Hence -DENABLE_QT='TRUE' is now -DENABLE_QT2='TRUE'
and Binaries/dolphin-emu-qt is now Binaries/dolphin-emu-qt2
which has to be removed within package_dolphin-emu-git():
rm -rf "${pkgdir}"/usr/bin/dolphin-emu-qt2

Hi,

Please remove the -DENABLE_SDL=TRUE, as it’s been deprecated on Linux, so libevdev will be used instead.

Also, have a run of namcap on the generated packages, you are missing things like hicolor-icon-theme or a .install script to run xdg-icon-resource.

Thanks.

Thanks for adding the "-fno-pie" flag. I've been relying on customize-pkg to patch the PKGBUILD for a while now seeing as this modification was previously refused.

Now Dolphin-git can be compiled and run without this annoying bug.

Thanks for the explanation, we do have ASLR enabled by default, I guess my play sessions were just never long enough to trigger the error.

Due to how memory allocation works, especially on a system without ASLR enabled. You may get lucky up until a point and it would be allocating memory in the virtual memory space <4GB.
Eventually this memory space will be exhausted and then at that point Dolphin will spit out an error.
So there is a variety of factors that can cause it to break immediately or still take a decent amount of play time due to luck.

Thanks for the info. I still can't help but wonder, if it completely breaks CPU emulation, why is it I have never experienced the issue nor got any bug report for the stable package in [community]? Does it really affect everyone or only a subset?

FTR, I have never explicitely enabled PIE, it's on by default, you might want to consider disabling it by default on everything not AArch64.

Anyway, just pushed an updated PKGBUILD.

Hello. Dolphin emulator developer here. I made an account on this just for this.

We've had dozens of users come to our IRC channel complaining about this. To the point that I've been copy and pasting the new cmake command required to work around this issue.

Your enabling PIE fundamentally breaks our x86_64 CPU recompiler. It isn't just "one" person having an issue with it. It completely breaks our CPU emulation!
It's easy enough to figure this out by attempting to launch any game with the version you compile!

So please, disable PIE like we require and hopefully in the future when someone decides to take the time to finish the work on x86_64 PIE support then you'll be able to re-enable the PIE flag.

Also another FYI. You /can/ enable pie on AArch64 builds of Dolphin if you so want. It's only the x86_64 architecture that mandates the feature to be disabled.

Not sure what you mean by "none of the other flasg are needed", also LTO does not slow down at compile time, it's called _link time_ optimization for a reason. Finally, this has been discussed before, I'm not sacrificing pie because one in a hundred people has troubles with it.

Needed to add -DCMAKE_CXX_FLAGS='fno-pie' and -DCMAKE_C_FLAGS='fno-pie' for it not to break when running games throwing writerest errors and crashing. None of the other flags are needed. LTO slows down compile.

Thank you alucryd.

Apologies for the late update, unfortunately I'm incredibly busy these days. The qt build was renamed qt2, updated the PKGBUILD accordingly.

Flagging out-of-date for the reason given in the previous comment.

Ok, building without dolphin-emu-qt-git works. The devs did indeed kill the qt branch. There are normally three split packages resulting out of this build. As long as you get two, dolphin-emu-cli-git and dolphin-emu-git, then you're good. You don't need dolphin-emu-qt-git. You can edit the PKGBUILD and MKPKG to remove those references or just build it and let it fail and you still have the two required packages as dolphin-emu-qt-git is packaged last anyway.

Getting the error here when trying to update Dolphin.

==> Starting package_dolphin-emu-qt-git()...
install: cannot stat ‘Binaries/dolphin-emu-qt’: No such file or directory
==> ERROR: A failure occurred in package_dolphin-emu-qt-git().
Aborting...
The build failed.

Still getting the error, can anyone else confirm? Any suggestions I could try and report back with?

Getting this error with r8583:

==> Starting package_dolphin-emu-qt-git()...
install: cannot stat ‘Binaries/dolphin-emu-qt’: No such file or directory
==> ERROR: A failure occurred in package_dolphin-emu-qt-git().
Aborting...

The Dolphin emulator team just did do some removal of functionality relating to unused QT code that might be the culprit here..

@alucryd

Sorry for the late answer, holidays in the middle of nowhere with terrible internet connection got in the way...

Yep, I can confirm this too, working fine now.

@alucryd

Yes. Tried it out just now, works perfectly for me.

Looks like it builds fine now, can you guys confirm?

@txus

Me too. dolphin-emu-nogui seems to link fine. I get an error for target 'GameFile.cpp.o' during linking of dolphin-emu-qt. Seems to be Qt related, but I'm not sure what is wrong. I would assume that the qt5 libraries in Arch are probably just much newer than what the dolphin team uses.

Has anyone been able to fix this?

Anybody else getting an error during/just after linking?

@txus

Thank you!

can you package maintainer change the PKGBUILD to not remove the build directory, instead discarding changes? this would save some bandwidth for users.

EDIT: i have found a solution to this issue. if anyone else wishes to do this, follow this page on the arch wiki.

this does not appear to be an issue with your PKGBUILD. but rather user configuration.

https://wiki.archlinux.org/index.php/Yaourt#Persistent_local_source_repositories

Is anybody else seeing ca conflict between dolphin-emu-git and dolphin-emu-qt-git? The PKGBUILD should have the line

"rm -rf "${pkgdir}"/usr/bin/dolphin-emu-qt"

at the end of the package section of dolphin-emu-git, else both packages end up having dolphin-emu-qt.

I can't get this to work - launching any game results in an andless procession of "WriteRest: op out of range (0x43f76122 uses 0x55b7913e7148)" (with variable hex addresses). Any suggestions?

EDIT: Got it to work by following the wiki's suggestions and building it with -fno-pie in CXX_FLAGS.

Well, it's not a build problem as the package now builds correctly. If it is an emulator problem then perhaps you should open an issue on their official tracker:

https://bugs.dolphin-emu.org/projects/emulator/issues/

Yes, but we (at least I, and I'm assuming a lot of the other people who are still having this problem need version) need version 7840 for netplay.

As of 7866 the miniupnpc issue is fixed:

https://github.com/dolphin-emu/dolphin/pull/3109

I compiled 7870 using this unmodified PKGBUILD and it now builds fine.

Doesn't compile since last miniupnpc update. Workaround is to add -DUSE_UPNP='FALSE' to cmake parameters.

Hi, I am able to build dolphin but the package won't install. looking through the comments I saw a similar problem from about a year back but didn't see a solution.

[100%] Built target dolphin-emu
==> Entering fakeroot environment...
==> Starting package_dolphin-emu-git()...
make: *** No rule to make target 'install'. Stop.
==> ERROR: A failure occurred in package_dolphin-emu-git().
Aborting...
==> ERROR: Makepkg was unable to build dolphin-emu-git.

Confirmed it's not needed anymore, also got rid of -fpermissive while I was at it. Thx for the reminder :)

-fno-inline-functions shouldn't be needed anymore (it was required to work around a gcc/wxgtk bug a few months ago). Given that it has the potential to decrease performance, I would suggest getting rid of it now.

Fair enough, I didn't realize the 4.0.x were on a hotfixes branch. Still several distros, including arch, packaged the 4.0.2 tarball in their repos. I still want the version of the git package to be superior to the one in the repos, so as a compromise I'll keep 4.0.2 but start counting revs from the 4.0 tag so that at least the rev number is identical to upstream builds.

Actually 4.0.1 and 4.0.2 were only released for Windows and master never got those merged in, so you should still use upstream versioning.

evdev just landed in master, PKGBUILD updated.

That change was merged in the stable branch, not the master branch. There is however a new dep on enet.
As for the version scheme, there is an official 4.0.2 release, as such 4.0.2.blah is the correct way to go, regardless of what upstream is advertising.

As of 4.0-6930, Dolphin dropped the dependency on sdl2 to add one on libevdev, for joystick support on Linux.

You might also want to change the version number to something closer to upstream, like 4.0.<number of commits>.<last commit hash>, instead of the current 4.0.2.r<number of commits>.<last commit hash>.

lolwut? First, dolphin is _not_ "designed to go" in /usr/local, second, do you even know where the themes and icons are stored? Anyway dolphin has always worked like this, and will always do, there's something wrong on your side, not with the package.

The cmake flag -DCMAKE_INSTALL_PREFIX='/usr' installs dolphin in /usr instead of /usr/local where it is designed to go. Because of this the themes do not load correctly, noticeable by the lack of icons and error message on startup. Can this flag be removed to avoid this issue?

I was having the same issue that you describe. I went to the dolphin irc for help and they noticed that I was linking polarssl from /usr/local/lib. I noticed then that it was using an old version that I must have gotten from trying out Tox, but then not bothering with it for a long time. After deleting my usr/local (tox was basically the only thing in there for me, but you should look for anything important) dolphin now compiles and runs just fine.

I have been having issues with write rest using dolphin-emu-git as well as dolphin-emu stable from extra. I recently reinstalled archbang, (the prior installation didn't have any issue with WriteRest in dolphin-emu.) I even tried using the git package from the older install, and no go. -fno-pie flag did not help with the latest git. I also tried one older than the version working on the older archbang install. Only dolphin-emu-qt gets into some games, even then, dolphin-emu-qt-git will not properly enter fullscreen mode and locks up when starting a game most of the time. Has anyone else had this issue (-fno-pie CXX-FLAG option not helping with WriteRest errors?)

I've been having an issue with bumblebee + dolphin-emu on the last build. I've been getting low FPS; anyone encounter the same?

Should be fixed upstream already.

I get the following build error...

In file included from /home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DolphinQt/GameList/GameFile.h:13:0,
from /home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DolphinQt/GameList/GameTracker.h:12,
from /home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DolphinQt/GameList/GameGrid.h:11,
from /home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DolphinQt/GameList/GameGrid.cpp:9:
/home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DiscIO/Volume.h: In member function ‘virtual u32 DiscIO::IVolume::Read32(u64, bool) const’:
/home/necbot/AUR/dolphin-emu-git/src/dolphin-emu/Source/Core/DiscIO/Volume.h:27:10: error: ‘Common’ has not been declared
return Common::swap32(temp);
^
Source/Core/DolphinQt/CMakeFiles/dolphin-emu-qt.dir/build.make:217: recipe for target 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu-qt.dir/GameList/GameGrid.cpp.o' failed
make[2]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu-qt.dir/GameList/GameGrid.cpp.o] Error 1
CMakeFiles/Makefile2:1160: recipe for target 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu-qt.dir/all' failed
make[1]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu-qt.dir/all] Error 2
Makefile:146: recipe for target 'all' failed
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

Those weren't my words, those came straight from the guys in the Dolphin IRC channel. I understand both points of view, but I tend to agree with yours. I just wish I knew why my system is in the minority having issues with PIE.

I don't know where you got the idea that we're adding PIE everywhere but you might want to check your source because we're doing no such thing... Have a look at /etc/makepkg.conf if you don't believe me, I don't see no -fPIE in there. Sure, there have been talks about enforcing it in [core], but nobody has yet to act on them. If you want to blame someone, blame CMake for enabling PIE by default, but certainly not Arch Linux.
Now if PIE did cut performances in half, I would gladly disable it in dolphin, but as long as it doesn't, the added security is welcome. The 1% having issues with it can just edit the PKGBUILD before building.

alucryd: They told me to tell the Arch guys to stop adding PIE to everything. So... yeah...

BrianAllred: Please report that upstream then, I will not give PIE up if only a few systems have problems with it.

Need to add '-fno-pie' to the CXX_FLAGS, or launching games will fail on some systems with a WriteRest error.

The PKGBUILD fails because the patch has already been applied. I commented out the patch line in prepare() and it compiles fine.

The patch has been applied upstream.

Patched, however I ran into some (unrelated) invalid conversions on the way, had to add -fmpermissive to the build flags.

Same here. Dolphin has always been relying on the FindOpenGL module from CMake to find the X11 libraries, however this module no longer looks for them as of CMake 3.2 so Dolphin has to do it itself from now on. I will produce a patch when I have some time.

Trying to compile using llvm 3.6 and mesa 10.5 from staging repo.


OpenAL found, enabling OpenAL sound backend
-- Found LLVM 3.6.0
X11 support disabled
CMake Error at CMakeLists.txt:458 (message):


No suitable display platform found

Requires x11 to run


-- Configuring incomplete, errors occurred!

Oh I should've added this to my msg as well; an FYI for those that don't know. You can run dolphin-emu with the -U flag, to move the user folder it uses.
(for example: 'dolphin-emu -U ~/.local/share/dolphin-emu')

Is it just me or does this dolphin version throw all the dolphin folders straight into ~/* as opposed to something like either ~/.dolphin/* or ~/.local/share/dolphin/* when you run it?

Thx for the heads up, dep changed.

polarssl was renamed to mbedtls. It existed with both names for a few days, but was removed recently. Can you update the dependencies with the new name? As far as I can tell, it doesn't effect the build process.

A VCS package can _never_ be out of date by nature [1], did you even try building the package before flagging out of date twice?

[1] https://wiki.archlinux.org/index.php/VCS_package_guidelines

This is out of date, the last version is 4.0-5517.127e742992597d553f6d54907d6b67d9d56c6cb1

I just split the PKGBUILD into the regular dolphin-emu-git which contains the wx build, dolphin-emu-cli-git for those who prefer th enogui build (binary is dolphin-emu-cli) and dolphin-emu-qt-git for those adventurous enough to try out the new and not yet shiny Qt build (binary is dolphin-emu-qt). In time, the Qt UI is meant to replace the Wx one.

ShalokShalom: I'm quite sure the "// XXX not 64-bit clean" comment on the offending line in CoreParameter.cpp means that upstream is aware of this. Anyway, feel free to drop a bug report on them if you'd like.

Upstream dont know this Issue at all and there is even no Bug Report about that.

malbeth: I'd rather not, first because it's against arch' policy to patch, and second because it's not a 100% reliable fix, if it was, upstream would have applied it a long time ago.

Could you include the 64 bit patch in the pkg ?

https://wiki.archlinux.org/index.php/Dolphin_Emulator#Dolphin_occasionally_crashes_on_64-bit_CPUs

I feel like I've answered this a million times already. The error is literally staring at you "/usr/lib/libavcodec.so: undefined reference to `x265_encoder_open_31'". You're most likely using an unsupported ffmpeg which you haven't rebuilt against libx265.
Please, people, please learn how to deal with these things before you use unsupported stuff, it's called unsupported for a reason :P

I get this error when compiling.

Linking CXX executable ../../../Binaries/dolphin-emu
/usr/lib/libavcodec.so: undefined reference to `x265_encoder_open_31'
collect2: error: ld returned 1 exit status
Source/Core/DolphinWX/CMakeFiles/dolphin-emu-nogui.dir/build.make:168: recipe for target 'Binaries/dolphin-emu-nogui' failed
make[2]: *** [Binaries/dolphin-emu-nogui] Error 1
CMakeFiles/Makefile2:611: recipe for target 'Source/Core/DolphinWX/CMakeFiles/dolphin-emu-nogui.dir/all' failed
make[1]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu-nogui.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/usr/lib/libavcodec.so: undefined reference to `x265_encoder_open_31'
collect2: error: ld returned 1 exit status
Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/build.make:1343: recipe for target 'Binaries/dolphin-emu' failed
make[2]: *** [Binaries/dolphin-emu] Error 1
CMakeFiles/Makefile2:569: recipe for target 'Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all' failed
make[1]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all] Error 2
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2

My bad, brain fart in last update. Should be fiexd now, thx for reporting.

It seems to build fine, but then the package still fails to be created.

Linking CXX executable ../../../Binaries/dolphin-emu
[100%] Built target dolphin-emu-nogui
[100%] Built target dolphin-emu
==> Entering fakeroot environment...
==> Starting package()...
make: *** No rule to make target 'install'. Stop.
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build dolphin-emu-git.
==> Restart building dolphin-emu-git ? [y/N]
==> ----------------------------------------
==>
==> ERROR: unable to update

Good for you.

@alucryd
I built Dolphin without the PKGBUILD, it works. Thank you.

That is just not possible, if dolphin found it at link time, it cannot not find it at run time. For starters, the current ffmpeg ships libavcodec.so.56, so either you built dolphin wrong, or you have a custom lib which links against the old ffmpeg that you haven't rebuilt.

@alucryd
I rebuilt Dolphin but I still get the same error.

Just rebuild against new ffmpeg.

I have been getting this error recently:
dolphin-emu: error while loading shared libraries: libavcodec.so.55: cannot open shared object file: No such file or directory

I don’t think it’s LTO that enabled nogui, but cd641bd0e344f1cab7ff23a1977fc37a958402da. Thanks for the updated PKGBUILD. :)

linkmauve: it seems enabling lto also enabled nogui, weird? Anyway you're right, now that it's built, might as well ship it too.

Sudowoodo: This is the last time you flag this package out-of-date without giving a valid reason, well even a reason at all. Next time I will suspend your account.

Now that cmake builds both wx and nogui binaries, you should also install dolphin-emu-nogui.

I've been getting this as well with my nvidia card, just switching between windowed and fullscreen fixes it for both gc and wii games.

@bluerider, thank You very much for response.
CPU: Core i5 3570
GPU: GTX 650 Ti
lspci: http://bpaste.net/show/616310/
generic /etc/makepkg.conf file: http://bpaste.net/show/616346/

I've got render image now if I double-switch screen mode by pressing alt + enter. But it works only for GC-games, not for Wii: (here is attempt to run every Wii-game: http://rghost.ru/57491243/image.png)

@Zeben: What's your hardware? I don't have this issue on a sandybridge IGP system, but I have it on a haswell IGP rig. For the haswell rig, when I use fullscreen, I can see the game.

Every build I have empty screen while trying to launch every game. No one errors or warnings I've got.
There is a screenshot: http://rghost.ru/57490921/image.png

P.S.
I have no this problem if I install dolphin-emu from [community] repo.
Can you reproduce this? And can this be by changing CFLAGS in /etc/makepkg.conf file?

Enabled LTO, dolphin builds fine with it here now. LTO is supposed to improve performance, although I didn't see much of a difference in the few games I launched. At least they weren't running slower :P

I ended up just adding your repository (Thank you) and pulled from that. It seems to have installed fine and is just as playable as stable, but unfortunately its also just as crashy(Segmentation faults) as the stable release 4.0.2 was for me. That and as I guessed previous version save states won't work with git version.

dolphin is built every night just fine for my nightly repo, I don't know what's going on with you guys, try to build in a clean chroot, that's what the build server does.

Yes, yes it is, got the same exact error a few minutes ago.

zwastik: Can't reproduce here, is it still happening?

I get this error:
Linking CXX executable ../../../Binaries/dolphin-emu
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libavcodec.so: referencia a `x265_encoder_open_16' sin definir
collect2: error: ld devolvió el estado de salida 1
Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/build.make:1309: recipe for target 'Binaries/dolphin-emu' failed
make[2]: *** [Binaries/dolphin-emu] Error 1
CMakeFiles/Makefile2:610: recipe for target 'Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all' failed
make[1]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all] Error 2
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2

cemegginson: You can find a fixed wxgtk and nightly builds of dolphin on my repo. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#alucryd

@alucryd I'd like to confirm that I also experience the same issue as sudsbud, but with the prebuilt package on the repos since I still haven't managed to get this one to compile due to the GCC 4.9 issue or whatever it is that's keeping it from compiling.

sudsbud: I can't reproduce this here on my laptop. I have bumblebee, using the intel driver or the nvidia blob works for me. I wouldn't say it's a driver issue, since there is no opengl involved when opening/closing the gamepad config window, but I have no idea where it could be coming from.

I got the same crash on nouveau, so my guess would be that it isn't driver related.

Yes, I do use the nvidia driver and have problems with every dolphin version I've tried. I talked to irc about it and someone suggested that it might be an nvidia driver problem ported over from the windows problem (driver version 334.89) with the opengl backend causing "frequent crashing."

I'm thinking about testing with my intel card just to make sure it's something in the driver and then I'll look into downgrading.

@sudsbud
Yes, I've been experiencing this exact problem for some time now, and on the stable release (4.0.2) as well. Are you using the NVIDIA driver by any chance?

Do any of you reproduce these crashes?
1: open gamepad window -> close gamepad window -> open gamepad window = crash
2: open game -> close game -> open game = crash
3: open gamepad window -> open game = crash
4: run in gdb -> open game = crash

Anyone know about these and has a work around?

Snowman hasn't showed up on IRC for a month, I still haven't got in touch with him, no activity on the bug report either. I'll shoot him an email when I find the time to take care of this, maybe next week, time is scarce these days.

This commit broke it again for me: https://github.com/dolphin-emu/dolphin/commit/91840cb4c77651179480f4c9480928b097296343

Probably the same gcc 4.9 bug...

Ok, removed i686 from the arch array, and added -fno-inline-functions only to the flags, no more editing yours. Thx for the heads up guys.

Also, now that I'm back, I'll ping Snowman about the bug report once he shows up on IRC.

i686 JIT will soon be removed (see https://dolphin-emu.org/blog/2014/05/19/obituary-32bit/), you should remove i686 from the arch array since it will become painfully slow.

Thx for the insight guys. I'll contact Snowman on IRC if he does not react to the bug report. He's usually pretty quick though, just have to wait that Scimmia assigns the report to him. I will try to update the PKGBUILD as soon as something moves, can't promise though as I'm currently abroad.

Build issues with this package are caused by https://bugs.archlinux.org/task/40497 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214

Motivated people might want to rebuild their wxgtk package from ABS using --disable-visibility as a ./configure option. Otherwise, wait and hope that the Arch bug report I made suggesting a workaround gets considered :)

@alucryd: The problem is caused by -finline-functions which is enabled by -O3, so to work around this you could just use "-O3 -fno-inline-functions".

I removed -DCMAKE_BUILD_TYPE='Release' as release is the default anyway. Also I'm modifying CFLAGS and CXXFLAGS in the PKGBUILD now so you don't even have to edit makepkg.conf. Enjoy.

mathieuI: I was thinking about adding it as a dep, so here it is. Also added a workaround for the link error.

The problem was caused by -O3, which seems to be the default optimization level of a Release build type for cmake. Overriding it with -O2 does the trick, however please make sure that your CFLAGS and CXXFLAGS in /etc/makepkg.conf does not contain -O3, it seems that when 2 optimization flags are passed, the highest takes precedence.

Also, could you either add polarssl to the dependencies array, or make this package conflict with it?

I encountered the linker issue last night on the nightly build server, GCC 4.9 is indeed most likely the culprit. Could somebody report this on dolphin's bug tracker?

boogerlad: Any compiled code is built with the flags you specify in /etc/makepkg.conf, just put march=native instead of your current arch, and remove mtune=generic. As for running dolphin, the JIT recompiler will use every extension available.
Also OpenMP texture decoding has had its checkbox for a long time, you might want to look at the GUI before looking at the code.

Is it possible to turn on openmp and sse if available on the host machine? I know at least https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/TextureDecoder_x64.cpp has optimizations there.

I have the same issue. I think this coincided with the upgrade of gcc to 4.9.

I got a VERY strange problem when linking. I got the following message:

Frame.cpp:(.text+0x61df): undefined reference to `wxCommandEvent::Clone() const'

After some routine checks about having all dependencies installed correctly, I started playing with the code and found that removing the following lines from src/dolphin-emu/Source/Core/DolphinWX/Frame.cpp made the program link:

else if (IsHotkey(event, HK_DECREASE_FRAME_LIMIT))
{
if (--SConfig::GetInstance().m_Framelimit > 0x19)
SConfig::GetInstance().m_Framelimit = 0x19;
}

However, I also noticed that (1) from the context, it doesn't make any sense that those lines are causing the problem, and (2) randomly playing with the file made the error return or go away, so it looks like a compiler or linker bug? I'm in testing BTW, maybe that's why.

Just commenting in case someone else knows about this or is also affected by the same problem.

Builds fine without indeed, nuked. Thx!

Dolphin upstream has removed opencl support (cited noone cared about maintaining it). Opencl-headers can probably be removed from makedepends

I just wanted to say that the windows managers really have a big effect on dolphin emulation. I just switched to the i3 windows manager, and I'm getting 50fps SuperSmash Brothers Brawl playback on my sandybridge i3-2105 (integrated gpu) at 1080p.

breed808: Thx for the heads up, I've switched to github.

It looks like development has moved to a github repository (https://github.com/dolphin-emu/dolphin). The Google Code repository is sitting at 4.0.r720.5d1db5d, while the github repo has been more recently updated (4.0.r773.70f66ad).
The commit links are pointing to the github repo as well.

I can't reproduce your problem, SDL2 works fine here. My 360 controller and my older Saitek gamepad are both recognized fine and work fine ingame.

I recommend use SDL and not SDL2 as dependency.
Because of the problems discussed here:
https://code.google.com/p/dolphin-emu/issues/detail?id=6768

Update (very sorry about the triple-post): it's not an upstream issue, the sdl2 2.0.1-1 package is bugged (https://bugs.archlinux.org/task/37484). It should be safe to upgrade to the 2.0.1-2 package when it becomes available.

Update (very sorry about the triple-post): it's not an upstream issue, the sdl2 1.0.1-1 package is bugged (https://bugs.archlinux.org/task/37484). It should be safe to upgrade to the 1.0.1-2 package when it becomes available.

Apologies for the double post: compilation appears to be failing due the to sdl2 update (2.0.0-4 --> 2.0.1-1). Downgrading the sdl2 package back to 2.0.0-4 solved the issue.

I'll report this upstream to the dolphin devs.

Getting a build error with the latest git version (4.0.265): http://pastebin.com/aFdNMLGB

Mannex: You do realize there is a pkgver function in there right?

bluerider: Nice, changelog said they enabled fastmem on linux and osx, leading to a 15-20% speed boost. The OpenGL plugin has also been largely rewritten (they claim it is now the fastest backend on NVIDIA cards :). Also, you can use HLE almost anywhere now, no more LLE! Welcome back, speed.

@alucryd : Wii games work again using Dolphin 4.0 and my intel i3-2105 cpu + gpu. Super Smash Brothers Brawl is running at full speed again.

upgrade version numbers to signify the new release as of yesterday. it has now reached 4.0-45 already.

New version. Now use GTK and more changes

techno-geek: It builds fine as is in a chroot. Where/how did you build the package?

I had to install package x264 or the compile would fail with:

/usr/bin/ld: warning: libx264.so.133, needed by /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib/libavcodec.so, not found (try using -rpath or -rpath-link)

@alucryd : Wii games currently don't work for me. When they were working I got close to full speed with Super Smash Brother Brawl. If I overclocked my iGPU, I would definitely get full speed Legend of Zelda Skyward Sword and Super Smash Brothers Brawl gameplay. I use an Asus Maximus Gene IV Z as my motherboard by the way.

Interestingly when compiling Dolphin-emu (instead of using the one provided by the Arch Community Repos), I can at least see movies from Super Smash Brothers Brawl and The Legend of Zelda Twilight Princess; the game stops (nondescript full crash) when I escape the movie portions of the game.

bluerider: A while ago you just dropped here "I can't play games on my low end system", without mentioning "it was a lot better before". Of course I would tell you to go bother dolphin's team, especially since the faq clearly states you need at least an i5 2500k to play comfortably.
Well glad it works now. Just out of curiosity, can you run games at fullspeed with an i3 and IGP? Games like Oboro Muramasa, I assume you could, but anything 3D would be a pain.

@alucryd : I think something just got busted up in cmake (not sure what it was); I did a full system re-install and it fixed things up. There have been issues with cmake passing compiler flags : <https://bbs.archlinux.org/viewtopic.php?pid=1249581#p1249581>
<https://bbs.archlinux.org/viewtopic.php?pid=1144646#p1144646>

In addition, I'm still using an i3 sandybridge processor (w/o discrete graphics) which meant the sse instructions gave my system a very large boost. I stated previously that the edition of dolphin-emu-git I was using has severely reduced performance compared to what I was used to; you told me to file a bug with dolphin upstream.

bluerider: I find 50% hard to believe, last time I checked, the difference from dolphin-emu 3.5 from the repo (built for generic arch) and the git version (around the time 3.5 was released) built for my ivy bridge didn't make that much of a difference. Then again, it can depend on a lot of things, and maybe some changes in dolphin made that optimizations got a lot of impact, I'll just take your word on that.
Weird that your makepkg.confg variables are not working, maybe check the syntax, or if they're being overridden by something else.

@alucryd : I just checked the compilation on another machine and found the makepkg.conf flags respected. There must be something wrong with my particular Arch Linux install.

@alucryd : I have those same settings in my makepkg.conf; yet after adding those lines in the CMakeLists.txt, my performance increased by 50%. I apologize for the ssee4.2 flag; I forgot to remove it when I posted it.

@alucryd : I have those same settings in my makepkg.conf; yet after adding those lines in the CMakeLists.txt, my performance increased by 50%. I apologize for the ssee4.2 flag; I forgot to remove it when I posted it.

bluerider: I knew there was a reason why I did not add anything about CFLAGS, they're already being used. There is no need to add anything to the PKGBUILD.
You coud have checked too before asking sth like this.

bluerider: Several things bother me:
- dolphin uses a dynamic recompiler, which automatically uses all available optimization for the most CPU intensive tasks, building static parts with them too will not speed up by much (if at all), but I agree it is better still
- -O3 is completely random and will not always result in a faster binary, I don't really want to add it, plus I hear it will be deprecated in GCC in the near future
- -msse4.2 will break dolphin on all systems which do not support SSE 4.2, I can't add it, plus it is added automagically by -march=native on SSE 4.2 systems
- finally we have variables in makepkg.conf for this, they're called CFLAGS and CXXFLAGS

I'll try to change the PKGBUILD to use CFLAGS by tomorrow.

Please add the following lines to the prepare() function in the PKGBUILD to build with system's native optimizations<https://code.google.com/p/dolphin-emu/wiki/Linux_Build>:

## compile to machine architecture
msg "Changing CMakeLists.txt to compile to native architecture..."
sed -i 's/add_definitions(-msse2)/add_definitions(-march=native -O3 -fno-stack-protector -pipe -g -msse4.2)/g' CMakeLists.txt &&
msg "Changed CMakeLists.txt to compile to native architecture"

This is new libpng's fault, nothing to worry about.

iCCP - sRGB Error.. ís emulator ou dependece?

Moved bluez deps to optdepends: some packages still depend on bluez4, which conflicts with bluez-libs. At least one of them must be installed before building dolphin-emu if you want to have bluetooth support.

pschmitt: It builds fine with bluez 5, I won't use an old lib unless there are issues with it. Will test my real wiimote this week-end.

pschmitt: My bad, added bluez-libs, but I realized I still had bluez 4 installed, will try building agains bluez 5 before replacing with bluez 4.

pschmitt: This is not enough to justify using an old lib when we have an up to date one available... Did you try building with bluez 5? It builds fine here, I have yet to try connecting a real wiimote but will probably test this week-end. Unless someone has already tried and can confirm it does not work, I'll leave regular bluez (well, bluez-libs, since bluez is now split) in there.

Bluez dependency should be updated to bluez4 (https://www.archlinux.org/todo/update-bluez-dependencies/)

Bluez dependency should be changed to bluez4 (https://www.archlinux.org/todo/update-bluez-dependencies/)

bluerider: These kind of complaints are irrelevant here, please address them on dolphin-emu's tracker.
Anyway do you have a discrete GPU? Do not expect this emulator to run well without one. BTW an i3 might not be the best option either, especially those operating at lower frequencies.
See here: http://dolphin-emu.org/docs/faq/

can't see to play Wii games with dolphin-emu-git 3.5.1173-1 on intel i3 system

Schala: Indeed, and that's 10-15 less lines per package, shared source code between makepkg and yaourt when $SRCDEST is set, shared source code across some packages (I'm thinking about my gnome-shell-extension-* packages which build from the same source) and other goodness :)

Pacman 4.1 sure makes this a lot easier. Don't have to routinely check git repos explicitly anymore for changes!

Updated package for pacman 4.1.

For those eager to build this with gcc 4.8.0, a soon to be merged patch is available here: http://markus.members.selfnet.de/dolphin/gcc48fix.patch

joelsc: Yep, haven't had time to look into it yet.

Doesn't seem to build with gcc 4.8

bluerider: These kind of complaints have nothing to do here, please post them on the dolphin-emu bug tracker.

After updating the package, it seems Super Smash Brothers Brawl only runs at half its original speed (I'm getting 30-40 fps).

GLSL-master was just merged. The opengl plugin has been reworked and dolphin does not depend on nvidia-cg anymore. Deps updated.

GLSL-master was just merged. The opengl plugin has been reworked and dolphin does not depend on nvidia-cg anymore. Deps updated.

Latest Git revision fixes the libpulse issue.

@Alucryd: That looks to be a linking issue, so header inclusion doesn't really matter. I haven't had a chance to test yet, but adding:

CXXFLAGS="${CXXFLAGS} -lpulse-simple

should get things working again :)

Schala: I do too, haven't had the time to look into it in depth though. First I thought they didn't include the headers from PA (or that their names had changed), but they did. I'll keep you posted.

Getting this recently:

[ 99%] Building CXX object Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Src/GLInterface/GLX.cpp.o
[100%] Building CXX object Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Src/GLInterface/X11_Util.cpp.o
[100%] Building CXX object Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Src/X11Utils.cpp.o
Linking CXX executable ../../../Binaries/dolphin-emu
../AudioCommon/libaudiocommon.a(PulseAudioStream.cpp.o): In function `PulseAudio::SoundLoop()':
PulseAudioStream.cpp:(.text+0x91): undefined reference to `pa_simple_new'
PulseAudioStream.cpp:(.text+0x102): undefined reference to `pa_simple_write'
PulseAudioStream.cpp:(.text+0x145): undefined reference to `pa_simple_free'
../AudioCommon/libaudiocommon.a(PulseAudioStream.cpp.o): In function `PulseAudio::PulseInit()':
PulseAudioStream.cpp:(.text+0x466): undefined reference to `pa_simple_new'
../AudioCommon/libaudiocommon.a(PulseAudioStream.cpp.o): In function `PulseAudio::Write(void const*, unsigned long)':
PulseAudioStream.cpp:(.text+0x4fc): undefined reference to `pa_simple_write'
../AudioCommon/libaudiocommon.a(PulseAudioStream.cpp.o): In function `PulseAudio::PulseShutdown()':
PulseAudioStream.cpp:(.text+0x4e5): undefined reference to `pa_simple_free'
collect2: error: ld returned 1 exit status
make[2]: *** [Binaries/dolphin-emu] Error 1
make[1]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all] Error 2
make: *** [all] Error 2

Small update to clean up deps.

@bluerider: Yes, and dolphin's code needs updating in this regard, but I don't think it is their priority at the moment, since 1.5 is still working fine.

@Alucryd : I got an error regarding sf::SocketTCP. In SFML 2.0, this has been deprecated in favor of sf::TcpSocket. This affects the Netplay.h and NetPlayServer.cpp files.

@Alucryd:

I checked the Cmake logs and you are right. After explicitly turning off the sfml check in CMakeLists.txt, I am now encountering the same error as the one you documented in your bug report.

@bluerider: I doubt you built it with sfml from [community]. dolphin-emu specifically requires sfml < 2.0, what you did is tell it there's sfml 2.0 in there (which isn't necessary, it finds it fine because that dir is the default) then it ran a version check on it and switched back to 1.5 from its externals because it's too high.

What I did is force dolphin to compile against 2.0 by removing the version check, and that didn't work.

@Alucryd: I saw your bug on dolphin-emu's board. I couldn't replicate your error, but I managed to compile dolphin-emu-git with the SFML2.0-rc3 package from Arch Linux Community database.

I changed your SFML flag to '-DSFML_INCLUDE_DIR=/usr/include/' since cmake was telling me if failed to read '/usr/include/SFML/SFML/Config.hpp', which doesn't exist. The flag is a bit misleading since it doesn't indicate where the SFML directory is, but rather where it's in.

I recompiled dolphin-emu-git with that flag and I have successfully tested Super Smash Brothers Melee and Brawl.

@Alucryd: I saw your bug on dolphin-emu's board. The CMAKE error I found was due to cmake trying to read /usr/include/SFML/SFML/Config.hpp (which doesn't exist). I modified "-DSFML_INCLUDE_DIR=/usr/include/sfml1.6" to be "-DSFML_INCLUDE_DIR=/usr/include/" and installed the SFML package from [community].

I recompiled dolphin-emu-git and fired up Super Smash Brothers Brawl and it works!

@bluerider: No problem, glad it works for you now. I've been running more tests with sfml1.6, not all games are affected. For example Zelda SS is fine, while both SMG are not. Weird.

BTW I've seen a significant boost lately, games like those I cited above run fullspeed both under Linux and Windows for me now, which was unthinkable not long ago. That and Wiimote Plus supported out of the box, dolphin under Linux is getting better and better!

I removed sfml1.6, and reinstalled dolphin-emu-git. Wii games run now. Thanks a lot!

@Alucryd: I use an Intel i3-2105 cpu + Asus Maximus IV Gene-Z. It comes with HD3000 graphics. I can play wii games (60fps) at lowered resolution slightly less than 1080p without overclocking the integrated graphics. The faq's old and based on misconceptions about hardware (and hardware setup). I've gotten SSF IV: AE (on windows 8) running at 1080p at full 60 fps running on my machine after overclocking the gpu.

Regarding sfml, I find it weird that 1.6 does not work, it should be compatible with 1.5 (which is provided with dolphin).
I just managed to get vba-m to compile against sfml1.6 and it seems to work great. I'll keep looking into it for dolphin, but for the time being, using the one provided should work.

@bluerider: BTW I'm surprised you can run the emulator on integrated graphics. Except for playing 2D games like Oboro Muramasa, it is highly recommended to have at least a dedicated graphics card to get decent framerates. Have a look at this: http://dolphin-emu.org/docs/faq/

Regarding sfml, I find it weird that 1.6 does not work, it should be comatible with 1.5 (which is provided with dolphin).
I just managed to get vba-m compile against sfml1.6 and it seems to work great. I'll keep looking into it for dolphin, but for the time being, using the one provided should work.

@bluerider: BTW I'm surprised you can run the emulator on integrated graphics. Unless for playing 2D games like Oboro Muramasa, it is highly recommended to have at least a dedicated graphics card to get decent framerates. Have a look at this: http://dolphin-emu.org/docs/faq/

Regarding sfml, I find it weird that 1.6 does not work, it should be comatible with 1.5 (which is provided with dolphin).
I just managed to get vba-m compile against sfml1.6 and it seems to work great. I'll keep looking into it for dolphin, but for the time being, using the one provided should work.

@bluerider: BTW I'm surprised you can run the emulator on integrated graphics. Unless for playing 2D games like Oboro Muramasa, it is highly recommended to have at least a dedicated graphics card to get decent framerates.

@bluerider: I just removed the sfml1.6 dep because it was the cause of the problem, why would I want to add it back? Using sfml1.6, I could launch games but the emulator froze as soon as some 3D appeared. Using the provided sfml works perfectly for me and if it still doesn't for you, I'm afraid the problem is elsewhere.

Those messages you see can be safely ignored. If you look at them you'll see that they're warnings, not errors, and they are for the AVI dumping, which has nothing to do with actual emulation.

@bluerider: I just removed the sfml1.6 dep because it was the cause of the problem, why would I want to add it back?
Those messages you see can be safely ignored. If you look at them you'll see that they're warnings, not errors, and they are for the AVI dumping functionnality, which has nothing to do with actual emulation.

In addition : I looked at the cmake build, and found this :
/tmp/packerbuild-1000/dolphin-emu-git/dolphin-emu-git/src/dolphin-emu/Source/Core/VideoCommon/Src/AVIDump.cpp: In static member function ‘static void AVIDump::AddFrame(uint8_t*, int, int)’:
/tmp/packerbuild-1000/dolphin-emu-git/dolphin-emu-git/src/dolphin-emu/Source/Core/VideoCommon/Src/AVIDump.cpp:317:16: warning: ‘int avcodec_encode_video(AVCodecContext*, uint8_t*, int, const AVFrame*)’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:4272) [-Wdeprecated-declarations]
/tmp/packerbuild-1000/dolphin-emu-git/dolphin-emu-git/src/dolphin-emu/Source/Core/VideoCommon/Src/AVIDump.cpp:317:85: warning: ‘int avcodec_encode_video(AVCodecContext*, uint8_t*, int, const AVFrame*)’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:4272) [-Wdeprecated-declarations]
/tmp/packerbuild-1000/dolphin-emu-git/dolphin-emu-git/src/dolphin-emu/Source/Core/VideoCommon/Src/AVIDump.cpp:336:13: warning: ‘int avcodec_encode_video(AVCodecContext*, uint8_t*, int, const AVFrame*)’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:4272) [-Wdeprecated-declarations]
/tmp/packerbuild-1000/dolphin-emu-git/dolphin-emu-git/src/dolphin-emu/Source/Core/VideoCommon/Src/AVIDump.cpp:336:76: warning: ‘int avcodec_encode_video(AVCodecContext*, uint8_t*, int, const AVFrame*)’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:4272) [-Wdeprecated-declarations]

@Alucryd
Despite having sfml1.6 installed, I still cannot run wii isos after rebuilding the package.

BTW : If it requires sfml1.6, you should probably list it as a dependency

@bluerider: Reverted the sfml thing. I don't know why but it seemed to work this morning while now it's clearly not. I guess we'll stick with building the version from the externals, it's not a long build anyway.

Emulator stopped working for me on Wii games (I use isos). I am using dolphin-emu-git 20130203-1, and xf86-video-intel 2.21.0-1. Problem still persisted after downgrading intel drivers.

Problem still persisted after downgrading intel driver.

Emulator stopped working for me on Wii games (I use isos). I am using dolphin-emu-git 20130203-1, and xf86-video-intel 2.21.0-1. I will downgrade my intel driver to see if the problem persists.

Added sfml1.6 dep back. I have found a workaround which makes it work.

Removed the sfml1.6 dep for now, pointing cmake to the right dirs does not work. I have filed a bug report about this.

Adopting, I'll try to update it today.

Sorry I am being busy so I can't maintain this package any more. Whoever has time and enthusiasm please adopt it.

Got the error : tar: Ignoring unknown extended header keyword `SCHILY.fflags'

Also, I checked the git website and it says the last source code released was on 1/06/2013.

Also, please change the upstream URL to http://dolphin-emu.org/, your URL has never been the official site, just one that tries to act like it is.

As of a few hours ago, Dolphin merged the linux-desktop-file branch into master. Perhaps you can update PKGBUILD and discard the one in sources.

Hey again, thx for the change last time. A patch to make the TR Wiimotes work has been submitted in the following bug report: http://code.google.com/p/dolphin-emu/issues/detail?id=5011#c155
Can you add it to your PKGBUILD? I've successfully used my TR Wiimote in a number of games thanks to this.

Hi, can you add wxgtk2.9 as a dependency and add this "-DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-2.9" to the cmake line to use the system wxgtk, building from the externals is quite long. Thx in advance.

Package needs lzo2 as a dependency

I'm having problems when compiling:

{standard input}: Assembler messages:
{standard input}:593: Error: invalid character (0x5) in operand 1
make[2]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/src/common/rendcmn.cpp.o] Error 1
make[1]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/all] Error 2
make: *** [all] Error 2

Seems like it requires some portaudio and openal

Cmake was fixed.

@TomBoshoven: You're welcome :) Here's the source package for the patched cmake: http://ompldr.org/vZGh5NQ/cmake-2.8.8-2.src.tar.gz The maintainer of cmake doesn't seem to be very active :(

Thx for the patch guys, it's building again! Still no bluez, pulseaudio, libav and all as you said sgsdxzy, better wait for this fix upstream.

Thx for the patch guys, it's building again!

Thanks for the explanation chenxiaolong. That makes sense.

@sgsdxzy: There's a bug in the new version of CMake which causes any CMakeLists.txt build file that uses pkg-config to fail (PKG_CONFIG_FOUND variable is undefined).

This has been fixed upstream and I've reported a bug for Arch Linux, so hopefully, it should be fixed soon.

Arch Linux bug page: https://bugs.archlinux.org/task/29545
Upstream bug page: http://www.cmake.org/Bug/view.php?id=13125

@TomBoshoven: Thanks. I temproary include your patch. It'a the behaviour change of CMake. Yesterday I used an older version and it was fine. Today I updated CMake and tried again and got the same result as you do. Since the patch has to modify the source(unless we do another meaningless copy), you'd better report it upstream. SFML1.7 and up can't be dynamically linked and you have to use the static 1.5 version. One more thing: I noticed that it can't recognize pkg-config and thus ffmpeg(libav) and more thing. Bluez, pulseaudio and soil may still need some name alternation as glib.

@TomBoshoven: I think that patch can be submitted upstream (well, at least the first part :D). I don't know any distro that uses 'glib' in the /usr/include directory, instead of 'glib-2.0'. Same thing with pangocairo :)

And the complete patch, which makes it build on my system.
This is quite ugly, but it works.
http://pastebin.com/ZQWHf3AR

Sorry for the spam, but this may help people build the package.

Turns out it has to do with the dependency on a very new version of wxWidgets which is not present on my system, causing it to build it itself.
My patch should work, but it gave a linker error on gthread-2.0 which happens because of some error in the Externals/wxWidgets3/CMakeLists.txt file.
It includes sets of libraries, but those sets are defined nowhere.

I have the exact same problem as Alucryd.
It works after I patch CMakeLists:
http://pastebin.com/Uh4N6Dz9

Maybe you can check whether the build on your system works with this patch?

I don't think I have any strange configurations on my system. (default Arch flags for compiling, no strange additions to PATH)

@Alucryd: The bit you said about wxgtk is true: version 2.9.4 is required, and I removed it. But for your first problem, I tried to compile it and it secceeded. Everything that I installed and was to be dynamically linked worked out as expected. So I can't help about your problem. I suspect whether you had misconfigured some PATH or compile flags.

Hey, probably not the best place to post this but can you guys reproduce this? http://pastebin.com/d0scausE
Several issues: bluez, pulseaudio and soil are installed on my system but not detected. sfml is installed and detected but dolphin still uses static version (not that I care, but it's intriguing). Finally an error about gthread-2.0, which is, from what I've read, part of glib2, and is installed.

BTW, you can remove the wxgtk dependency sgsdxzy. This requires at least 2.9.4 when arch's version is 2.8.12, adding a version requirement on wxgtk would simply break the package, so I think removing it is the best option, people who don't use wxgtk won't have to install it for nothing, and dolphin will still use its internal version.

@akspecs：The difference is here:_gitname=dolphin-emu vs_gitname=dolphin-emu-3.0. That's stable 3.0 released 9 months ago while this one is the latest git version. gcc4.7 changed behaviour slightly, and you need to include <unistd.h>. The 3.0 branch can't receive bugfixes, so the AUR maintainer added a patch. The gcc problem is said to be fixed and no patch is necessary for the git version.

Here's the report I submitted :
http://code.google.com/p/dolphin-emu/issues/detail?id=5353

I noticed that the other dolphin-emu has been updated. At this point what makes dolphin-emu different from this PKGBUILD? Both fail to build on one of my systems, and both are looking like they're installing the latest that the git repo provides.

@akspecs:According to issue 5347, it's having problems with gcc4.7. But your problem doesn't look like that. I will have a try later. Please consider report an issue upstream.

Any help would be appreciated - I'm running on the ck kernel with propietary nvidia graphics:

/tmp/yaourt-tmp-aak/aur-dolphin-emu-git/src/dolphin-emu/Externals/wxWidgets3/include/wx/filefn.h:476:9: error: zero width for bit-field ‘wxAssert_477::BadFileSizeType’
make[2]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/src/aui/auibar.cpp.o] Error 1
make[1]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build dolphin-emu-git.

/tmp/yaourt-tmp-aak/aur-dolphin-emu-git/src/dolphin-emu/Externals/wxWidgets3/include/wx/filefn.h:476:9: error: zero width for bit-field ‘wxAssert_477::BadFileSizeType’
make[2]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/src/aui/auibar.cpp.o] Error 1
make[1]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build dolphin-emu-git.

Okay, turns out the culprit was cache display lists, I'll post an issue on google code.

Hey huys, I've got a problem running dolphin here. Everything builds fine with gcc 4.6.3, I'm using xorg 1.11.4 with latest fglrx (direct rendering works) and the linux-ck kernel, however the emu will shut down without any error almost immediately on a lot of games. Most of the time it's right after intro the video or static screens, it crashes silently before displaying some 3D sequences. Like the title screen in Zelda WW and TP, SMG, SSBB etc... Only game I tested that worked so far is Final Fantasy Crystal Chronicles. It doesn't crash at all.
I can't provide any log because they're empty, I'm really at a loss here. Does any of you have the same issue?

@Amarus
Exactly.

It did build for me now (without flags) but I think it was this that fixed it:
https://code.google.com/p/dolphin-emu/source/detail?r=b69a1d225a0736a1fabbb6b03bcdb5815f681de0

Not the bluez update.

I used to have the same error, but it is building now, after updating to Bluez 4.99-1.

In fact, I have tried the bluez patch before Arch updated it and got the same error. When I said -fpermissive, the bluez had some problem linking with CXX. Then a patch was applied and it broke bluez totally……Now -fpermissive doesn't work and you'd better uninstall bluez.

Not working for me either (with and without the flags), I'm getting the same errors as neXyon.

Still not working. :-(

It may be another problem. Bluez has just got updated to 4.99

Even with adding -fpermissive to CXXFLAGS and CFLAGS any way mentioned in the comments here I still/always get:

[ 68%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/Src/HW/Wiimote.cpp.o
In file included from /tmp/yaourt-tmp/aur-dolphin-emu-git/src/dolphin-emu/Source/Core/Core/Src/HW/WiimoteReal/WiimoteRealBase.h:26:0,
from /tmp/yaourt-tmp/aur-dolphin-emu-git/src/dolphin-emu/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.h:24,
from /tmp/yaourt-tmp/aur-dolphin-emu-git/src/dolphin-emu/Source/Core/Core/Src/HW/Wiimote.cpp:5:
/usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_le64(void*)':
/usr/include/bluetooth/bluetooth.h:131:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:131:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:131:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:131:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:131:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:131:9: error: 'struct bt_get_le64(void*)::<anonymous>' has no member named '__v'
/usr/include/bluetooth/bluetooth.h: In function 'uint64_t bt_get_be64(void*)':
/usr/include/bluetooth/bluetooth.h:136:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:136:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:136:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:136:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:136:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:136:9: error: 'struct bt_get_be64(void*)::<anonymous>' has no member named '__v'
/usr/include/bluetooth/bluetooth.h: In function 'uint32_t bt_get_le32(void*)':
/usr/include/bluetooth/bluetooth.h:141:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:141:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:141:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:141:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:141:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:141:9: error: 'struct bt_get_le32(void*)::<anonymous>' has no member named '__v'
/usr/include/bluetooth/bluetooth.h: In function 'uint32_t bt_get_be32(void*)':
/usr/include/bluetooth/bluetooth.h:146:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:146:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:146:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:146:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:146:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:146:9: error: 'struct bt_get_be32(void*)::<anonymous>' has no member named '__v'
/usr/include/bluetooth/bluetooth.h: In function 'uint16_t bt_get_le16(void*)':
/usr/include/bluetooth/bluetooth.h:151:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:151:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:151:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:151:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:151:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:151:9: error: 'struct bt_get_le16(void*)::<anonymous>' has no member named '__v'
/usr/include/bluetooth/bluetooth.h: In function 'uint16_t bt_get_be16(void*)':
/usr/include/bluetooth/bluetooth.h:156:9: error: expected identifier before '*' token
/usr/include/bluetooth/bluetooth.h:156:9: error: expected ',' or '...' before '(' token
/usr/include/bluetooth/bluetooth.h:156:9: error: expected ';' at end of member declaration
/usr/include/bluetooth/bluetooth.h:156:9: error: '__v' does not name a type
/usr/include/bluetooth/bluetooth.h:156:9: error: 'typeof' was not declared in this scope
/usr/include/bluetooth/bluetooth.h:156:9: error: 'struct bt_get_be16(void*)::<anonymous>' has no member named '__v'
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/Src/HW/Wiimote.cpp.o] Error 1
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
make: *** [all] Error 2

@sgsdxzy: Yeah, you're probably right. I just saw that C was also used (project statistics at https://code.google.com/p/dolphin-emu/).

I'm currently in class right now, so I can't test, but bluez just got updated and a patch was included: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/bluez&id=1e8615b5bfcdbd34a70dd66c620f91fc54972790

Maybe the build issue is fixed?

@chenxiaolong
But dolphin is written in C++
It used to be
……
_gitname=dolphin-emu
CXXFLAGS="-fpermissive"

build() {
……
Although it override user-specific CXXFLAGS, it worked fine. No CFLAGS is needed.

Oh, crap. I forgot: bluez is written in C, not C++, so the following is also needed:

export CFLAGS="${CFLAGS} -fpermissive"

I had added -fpermissive in the PKGBUILD using the line from @chenxiaolong.

export CXXFLAGS="${CXXFLAGS} -fpermissive"

Uninstalling bluez fixed it for me though.

@rlipman
I can't figure out why adding -fpermissive to your CXXFLAGS don't work. How do you add it?
First, you can use that patch for bluez.
Or, simply uninstall bluez and compile dolphin. If you don't need to use a real wiimote, wiiuse and bluez isn't dependencies.

I have the same build problem as @peacememories, but adding -fpermissive to my CXXFLAGS didn't fix it. Is there a way to build it without bluez and avoid this issue in the meantime?

I also found out the issue is a bug in bluez, not in dolphin

http://marc.info/?l=linux-bluetooth&m=132843961422749&w=2

Ahhh...sorry. I should have looked at the PKGBUILD before speaking :) I agree with you on your point. It's pointless to make a copy since most build systems can build in a separate directory.

(when I first used Arch, I had no idea that /tmp was a ramfs. I tried to build chromium-git in /tmp and wondered why the computer froze...:D)

@chenxiaolong
What you do is in {_gitname}/build/ cmake..
What I do is in {_gitname}-build/ cmake ../{_gitname}
That's same. No copy is needed.
What it used to do is copy contents in {_gitname}/ to {_gitname}-build and in {_gitname}-build/build cmake ..
I found almost every PKGBUILD with git and cmake do the copy…… Some source can reach 1G+ and the copy is just a waste of time and space especially for those use yaourt's default build location and mount /tmp to ram……

@sgsdxzy: Actually, if you want you can just have ${_gitname}/ and then:

if [ -d build ]; then rm -rf build; fi
mkdir build
cmake ......

There's no need to make any copy, since building from a subdirectory does not modify the original code (with CMake). Also, it will not affect later builds :)

Thanks to chenxiaolong. Another thing to notify is that it now won't do a meaningless copy of the source code. It starts cmake in ${_gitname}-build instead of ${_gitname}-build/build.

For those who don't want to alter the global CXXFLAGS, the following can be added to the PKGBUILD (anywhere before the cmake line):

export CXXFLAGS="${CXXFLAGS} -fpermissive"

Rewrite for dependencies. Note: for use of bluez, you need to add -fpermissive in your CXXFLAGS.

updated

@peacememories:
It may be a problem upstream. I will see to it.

For the record: activating -fpermissive flags "solves" the problem.
Please add that to the PKGBUILD (at least temporarily. I suppose there should be a fix for bluez soon? hopefully?)

Got a problem here:
In file included from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/WiimoteReal/WiimoteRealBase.h:26:0,
from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.h:24,
from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/Wiimote.cpp:5:
/usr/include/bluetooth/bluetooth.h: In function ‘uint64_t bt_get_le64(void*)’:
/usr/include/bluetooth/bluetooth.h:131:9: error: invalid conversion from ‘void*’ to ‘bt_get_le64(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint64_t bt_get_be64(void*)’:
/usr/include/bluetooth/bluetooth.h:136:9: error: invalid conversion from ‘void*’ to ‘bt_get_be64(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint32_t bt_get_le32(void*)’:
/usr/include/bluetooth/bluetooth.h:141:9: error: invalid conversion from ‘void*’ to ‘bt_get_le32(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint32_t bt_get_be32(void*)’:
/usr/include/bluetooth/bluetooth.h:146:9: error: invalid conversion from ‘void*’ to ‘bt_get_be32(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint16_t bt_get_le16(void*)’:
/usr/include/bluetooth/bluetooth.h:151:9: error: invalid conversion from ‘void*’ to ‘bt_get_le16(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint16_t bt_get_be16(void*)’:
/usr/include/bluetooth/bluetooth.h:156:9: error: invalid conversion from ‘void*’ to ‘bt_get_be16(void*)::<anonymous struct>*’ [-fpermissive]
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/Src/HW/Wiimote.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/WiimoteEmu/../WiimoteReal/WiimoteRealBase.h:26:0,
from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/WiimoteEmu/../WiimoteReal/WiimoteReal.h:24,
from /tmp/dolphin-emu-git/src/dolphin-emu-build/Source/Core/Core/Src/HW/WiimoteEmu/WiimoteEmu.cpp:27:
/usr/include/bluetooth/bluetooth.h: In function ‘uint64_t bt_get_le64(void*)’:
/usr/include/bluetooth/bluetooth.h:131:9: error: invalid conversion from ‘void*’ to ‘bt_get_le64(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint64_t bt_get_be64(void*)’:
/usr/include/bluetooth/bluetooth.h:136:9: error: invalid conversion from ‘void*’ to ‘bt_get_be64(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint32_t bt_get_le32(void*)’:
/usr/include/bluetooth/bluetooth.h:141:9: error: invalid conversion from ‘void*’ to ‘bt_get_le32(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint32_t bt_get_be32(void*)’:
/usr/include/bluetooth/bluetooth.h:146:9: error: invalid conversion from ‘void*’ to ‘bt_get_be32(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint16_t bt_get_le16(void*)’:
/usr/include/bluetooth/bluetooth.h:151:9: error: invalid conversion from ‘void*’ to ‘bt_get_le16(void*)::<anonymous struct>*’ [-fpermissive]
/usr/include/bluetooth/bluetooth.h: In function ‘uint16_t bt_get_be16(void*)’:
/usr/include/bluetooth/bluetooth.h:156:9: error: invalid conversion from ‘void*’ to ‘bt_get_be16(void*)::<anonymous struct>*’ [-fpermissive]
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/Src/HW/WiimoteEmu/WiimoteEmu.cpp.o] Error 1
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
make: *** [all] Error 2

Apparently a problem with bluez, but I have no idea how to fix it. Please help!

works well

@kiodo1981:
You can change the settings in the /etc/makepkg.conf so that it will benefit every package you build. Look here:https://wiki.archlinux.org/index.php/Makepkg
So I don't think it a good idea to add these lines to this specific PKGBUILD. Instead, you can add them in the global settings.

-> So now dolphin-emu is compiled and optimized for my platform?

Exactly. It's optimized for your specific CPU, so it's unlikely that it will run on any computer if you copy over the compiled binaries.

-> If so, why don't you update this PKGBUILD?

I'm not the maintainer of this package :) Also, I never really though about optimizing the binaries to make it run faster, only the configuration.

-> I found this optimizations: add_definitions(-march=native -O3 -fno-stack-protector -pipe -g)

I think that was added by the 3 lines in the new PKGBUILD. I can't seem to find that in the original source code.

-> What is the command I have to run to find out cores / threads to change make-j8?

You can find it by running "lscpu". The "make -j#" won't affect the compiled program, though. It just speeds up the compile time a lot :)

What is the command I have to run to find out cores / threads to change make-j8?

What is the command I have to run to find out cores / threads to change make-j8?

EDIT:
I found this optimizations: add_definitions(-march=native -O3 -fno-stack-protector -pipe -g)

Thank you.
So now dolphin-emu is compiled and optimized for my platform?
If so, why don't you update this PKGBUILD?

Hmm...maybe the optimizations should be added to this PKGBUILD. When playing New Super Mario Bros Wii at 1920x2160 (dual monitor) resolution with frame limit and audio throttle turned off, I get 85 FPS without optimizations and 92 FPS with optimizations.

I used the optimizations in my PKGBUILD below: "-march=native -mtune=native -O3" on my Core i7 2720qm and nVidia Quadro 2000m.

@kiodo1981: Oops, forgot to paste the PKGBUILD link. Just download the tarball from this page (https://aur.archlinux.org/packages/do/dolphin-emu-git/dolphin-emu-git.tar.gz) and replace the PKGBUILD inside with this one: http://pastie.org/pastes/2987258/text
).

@kiodo1981:

1. Try this PKGBUILD:

It compiles with the highest optimization (-O3) for your CPU (-march=native -mtune=native). Change the "make -j 8" line to the number of cores/threads your CPU has to speed to the compile time.

2. What patches are you talking about? Patches to the source code can be done by adding a

patch -Np1 -i /path/to/patch.diff

line to the PKGBUILD. Game memory patches, such as cheatcodes, etc, are done in the GUI after installing this package. If you want to patch the game disk (to modify files, levels in the game), you will need to use a program, like wit (https://aur.archlinux.org/packages.php?ID=37504).

3. Simply put, it's not possible. You might be able to achieve a cross compile, if you write your own CMake platform script to compile with mingw32 (or mingw64), but in my opinion, that's way too much work for a simple task. Plus, you'll lose the DirectX plugins, since the DirectX SDK is only available for Windows. If you use Windows, you can use tortoise-git to clone the git repository and use the express edition of Visual Studio to compile dolphin-emu. A tutorial on how to do that is at the dolphin-emu wiki: https://code.google.com/p/dolphin-emu/wiki/Windows_Build

Hello, I have three questions:
1. how can I add optimization for the CPU?
2. how to add the patches?
3. I compile from Linux to Windows?
Thank you.

Updated PKGBUILD

I'm working with Windows for the time being and thus can't make a new tarball.
Please install portaudio manually.

You must install portaudio to start the emulator.
This is new PKGBUILD 11 October 2011.
http://www.mediafire.com/?il7f6r8a2lfoclh

You must install portaudio to start the emulator.

@Mystro256: Thanks,the website has been changed to http://www.dolphin-emulator.com/
@Huulivoide: Thanks for your idea, but this is for the ones who have a slow network connection so that they don't need to redownload the entire source but the differed part. Besides, this is the standard git PKGBUILD which gives users a clone of source.

Mayby you could skip the source dir copying
and instead instruck cmake to read the files
straigt from the git-dir. cmake works well
in these kind of situations

cmake ../${_gitname} .....

The website should be set to http://www.dolphin-emulator.com/ or http://code.google.com/p/dolphin-emu/ ;P

Because of branches change(develop merged into master), I updated the PKGBUILD. Whoever downloaded the tarball and uses makepkg himself should delete src directory or git can't find the new branch. This won't affect yaourt as it reclones the entire source every time it runs.

@sgsdxzy: Thanks for updating the package so quickly :)

Thanks to chenxiaolong. I didn't know much about git, just transfered the svn version into a git one and forgot the check step. Now it should work better.

Please update PKGBUILD with this: http://pastebin.com/raw.php?i=Tmk9BnE1

I have modified it so that the entire git branch doesn't have to be "recloned" after every update. Hopefully this will help those with slow internet connections.

thanks for pkgbuild.. but, why change for git?
I see in the google code and not understand...