Package Details: dolphin-emu-git 5.0.r27.64cf74a-1

Git Clone URL: https://aur.archlinux.org/dolphin-emu-git.git (read-only)
Package Base: dolphin-emu-git
Description: A GameCube / Wii / Triforce emulator
Upstream URL: http://www.dolphin-emu.org/
Licenses: GPL
Conflicts: dolphin-emu
Provides: dolphin-emu
Submitter: None
Maintainer: alucryd
Last Packager: alucryd
Votes: 80
Popularity: 1.243032
First Submitted: 2011-08-20 13:05
Last Updated: 2016-06-25 16:41

Latest Comments

Martchus commented on 2016-08-05 11:30

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

krakn commented on 2016-08-05 01:21

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)

cubethethird commented on 2016-08-01 14:40

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

alucryd commented on 2016-08-01 08:44

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

cubethethird commented on 2016-07-31 23:06

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!

Martchus commented on 2016-07-31 22:51

The fix is merged now :-)

Martchus commented on 2016-07-29 17:29

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

bl4ckout commented on 2016-07-29 16:46

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

DrDoctor commented on 2016-07-27 15:07

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

alucryd commented on 2016-07-04 19:41

Can't reproduce, probably fixed upstream.

DrDoctor commented on 2016-07-02 13:32

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

mralext20 commented on 2016-07-02 00:32

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

thejacer87 commented on 2016-06-30 03:19

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

alucryd commented on 2016-06-26 07:30

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.

ammonaur commented on 2016-06-25 19:44

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.

alucryd commented on 2016-06-25 16:48

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 :)

oxalin commented on 2016-06-25 01:57

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"?

linkmauve commented on 2016-06-19 02:42

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.

nicman23 commented on 2016-05-06 11:35

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

Neros commented on 2016-04-15 23:18

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 :(

Martchus commented on 2016-03-16 17:57

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.

SuperIce97 commented on 2016-03-16 04:45

@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?

Neros commented on 2016-03-09 17:14

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?

Martchus commented on 2016-02-29 14:34

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.

rubic commented on 2016-02-29 07:18

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

Martchus commented on 2016-02-28 22:23

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

linkmauve commented on 2016-02-26 11:24

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.

Yann.O commented on 2016-02-02 21:39

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.

alucryd commented on 2016-01-21 14:20

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.

Sonicadvance1 commented on 2016-01-21 08:21

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.

alucryd commented on 2016-01-21 07:33

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.

Sonicadvance1 commented on 2016-01-20 23:10

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.

alucryd commented on 2016-01-20 07:22

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.

piccaruse commented on 2016-01-20 06:07

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.

headkase commented on 2016-01-19 11:08

Thank you alucryd.

alucryd commented on 2016-01-19 09:55

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

headkase commented on 2016-01-09 07:20

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

headkase commented on 2016-01-09 07:00

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.

samkostka commented on 2016-01-08 22:59

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.

headkase commented on 2016-01-08 18:47

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

headkase commented on 2016-01-06 15:32

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..

txus commented on 2015-12-27 15:53

@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.

c_t commented on 2015-12-20 15:11

@alucryd

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

alucryd commented on 2015-12-20 12:05

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

c_t commented on 2015-12-16 11:24

@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?

txus commented on 2015-12-15 20:42

Anybody else getting an error during/just after linking?

godofgrunts commented on 2015-11-09 03:06

@txus

Thank you!

mralext20 commented on 2015-11-05 17:34

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

txus commented on 2015-10-28 07:59

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.

gourdcaptain commented on 2015-10-17 19:27

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.

headkase commented on 2015-10-01 13:23

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/

aereaux commented on 2015-10-01 02:55

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.

headkase commented on 2015-09-30 22:55

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.

mus commented on 2015-09-29 17:42

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

bdv commented on 2015-09-12 20:06

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.

alucryd commented on 2015-08-30 09:37

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

delroth commented on 2015-08-29 22:15

-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.

alucryd commented on 2015-07-17 21:47

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.

linkmauve commented on 2015-07-17 21:28

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.

alucryd commented on 2015-07-06 07:50

evdev just landed in master, PKGBUILD updated.

alucryd commented on 2015-07-03 08:26

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.

linkmauve commented on 2015-07-03 00:36

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>.

alucryd commented on 2015-06-20 06:30

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.

rubic commented on 2015-06-20 05:06

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?

sudsbud commented on 2015-06-07 21:06

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.

thygar392 commented on 2015-05-24 16:39

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?)

bluerider commented on 2015-05-15 22:20

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

alucryd commented on 2015-04-21 08:59

Should be fixed upstream already.

necbot commented on 2015-04-21 01:08

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...

BrianAllred commented on 2015-04-02 12:34

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.

alucryd commented on 2015-04-02 07:24

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.

BrianAllred commented on 2015-04-02 02:55

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

alucryd commented on 2015-03-30 12:28

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

BrianAllred commented on 2015-03-27 21:21

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

bluerider commented on 2015-03-16 02:41

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

mac1202 commented on 2015-03-15 16:24

The patch has been applied upstream.

alucryd commented on 2015-03-13 11:59

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

alucryd commented on 2015-03-13 11:32

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.

agapito commented on 2015-03-12 13:33

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!

Omar007 commented on 2015-03-07 18:20

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')

Omar007 commented on 2015-03-07 18:07

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?

alucryd commented on 2015-03-07 16:57

Thx for the heads up, dep changed.

jakebailey commented on 2015-03-07 08:07

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.

alucryd commented on 2015-02-18 10:18

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

hertog commented on 2015-02-17 23:15

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

alucryd commented on 2015-02-02 11:14

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.

alucryd commented on 2015-02-01 15:00

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.

ShalokShalom commented on 2015-02-01 00:12

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

alucryd commented on 2015-01-19 10:35

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.

malbeth commented on 2015-01-18 03:16

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

alucryd commented on 2014-11-27 08:26

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

z1lt0id commented on 2014-11-27 00:12

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

alucryd commented on 2014-10-23 13:26

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

aphirst commented on 2014-10-23 13:19

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

alucryd commented on 2014-10-02 16:52

Good for you.

Sudowoodo commented on 2014-10-02 16:42

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

alucryd commented on 2014-10-02 15:07

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.

Sudowoodo commented on 2014-10-02 11:59

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

alucryd commented on 2014-09-28 08:34

Just rebuild against new ffmpeg.

Sudowoodo commented on 2014-09-28 08:33

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

linkmauve commented on 2014-08-19 08:06

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

alucryd commented on 2014-08-17 11:54

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.

linkmauve commented on 2014-08-17 09:24

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

alucryd commented on 2014-08-15 21:21

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.

Zeben commented on 2014-08-15 21:13

@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)

bluerider commented on 2014-08-15 20:59

@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.

Zeben commented on 2014-08-15 20:56

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?

alucryd commented on 2014-08-14 23:01

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

Retro_Gamer commented on 2014-07-31 09:04

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.

alucryd commented on 2014-07-14 23:58

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.

Retro_Gamer commented on 2014-07-14 23:51

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

alucryd commented on 2014-07-07 09:30

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

zwastik commented on 2014-07-06 03:19

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

alucryd commented on 2014-06-22 09:36

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

cemegginson commented on 2014-06-21 23:25

@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.

alucryd commented on 2014-06-21 10:09

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.

sudsbud commented on 2014-06-21 02:15

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

sudsbud commented on 2014-06-20 07:14

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.

breed808 commented on 2014-06-20 05:29

@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?

sudsbud commented on 2014-06-20 05:27

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?

alucryd commented on 2014-06-19 10:09

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.

AdrianoML commented on 2014-06-06 01:12

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

Probably the same gcc 4.9 bug...

alucryd commented on 2014-06-02 12:35

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.

linkmauve commented on 2014-05-25 12:02

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.

alucryd commented on 2014-05-22 22:41

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.

delroth commented on 2014-05-22 21:51

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 :)

Tilka commented on 2014-05-15 10:12

@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".

alucryd commented on 2014-05-09 09:58

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.

alucryd commented on 2014-05-09 09:14

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.

mathieuI commented on 2014-05-09 08:32

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

alucryd commented on 2014-05-05 17:45

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.

boogerlad commented on 2014-05-05 17:16

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.

jakebailey commented on 2014-05-03 07:39

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

d7s2qmspe7q48 commented on 2014-05-02 13:17

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.

alucryd commented on 2014-04-05 13:53

Builds fine without indeed, nuked. Thx!

bluerider commented on 2014-04-04 19:07

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

bluerider commented on 2014-03-27 01:45

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.

alucryd commented on 2014-02-03 10:55

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

breed808 commented on 2014-02-02 11:31

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.

alucryd commented on 2014-01-04 09:28

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.

oangelo commented on 2014-01-04 02:27

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

breed808 commented on 2013-10-26 14:32

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.

breed808 commented on 2013-10-26 14:31

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.

breed808 commented on 2013-10-26 12:28

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.

breed808 commented on 2013-10-26 12:17

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

alucryd commented on 2013-09-23 23:40

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.

bluerider commented on 2013-09-23 23:22

@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.

DyrverE commented on 2013-09-23 19:59

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

son_link commented on 2013-09-23 15:13

New version. Now use GTK and more changes

alucryd commented on 2013-08-30 07:51

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

techno-geek commented on 2013-08-29 19:16

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)

bluerider commented on 2013-08-07 00:46

@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.

alucryd commented on 2013-08-06 10:15

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.

bluerider commented on 2013-08-05 22:14

@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.

alucryd commented on 2013-08-05 18:31

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.

bluerider commented on 2013-08-05 16:47

@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.

bluerider commented on 2013-08-05 16:42

@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 commented on 2013-08-05 16:38

@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 commented on 2013-08-05 16:23

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.

alucryd commented on 2013-08-05 09:44

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.

bluerider commented on 2013-08-05 02:09

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"

alucryd commented on 2013-06-22 09:27

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

Anonymous comment on 2013-06-22 05:32

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

alucryd commented on 2013-06-10 08:20

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.

alucryd commented on 2013-06-07 12:50

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.

alucryd commented on 2013-06-07 12:42

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.

alucryd commented on 2013-06-07 12:36

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.

pschmitt commented on 2013-06-07 11:21

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

pschmitt commented on 2013-06-07 11:21

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

alucryd commented on 2013-05-31 20:11

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/

bluerider commented on 2013-05-31 14:49

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

alucryd commented on 2013-04-06 12:00

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 :)

Schala commented on 2013-04-06 08:14

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

alucryd commented on 2013-04-04 18:00

Updated package for pacman 4.1.

alucryd commented on 2013-04-03 11:01

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

alucryd commented on 2013-04-02 20:19

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

joelsc commented on 2013-04-02 20:09

Doesn't seem to build with gcc 4.8

alucryd commented on 2013-04-01 21:49

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

bluerider commented on 2013-04-01 18:18

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

alucryd commented on 2013-03-16 09:42

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

alucryd commented on 2013-03-16 09:42

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

Schala commented on 2013-03-03 10:49

Latest Git revision fixes the libpulse issue.

chenxiaolong commented on 2013-03-03 07:37

@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 :)

alucryd commented on 2013-03-02 14:29

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.

Schala commented on 2013-03-02 09:53

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

alucryd commented on 2013-02-04 23:16

Small update to clean up deps.

alucryd commented on 2013-02-04 22:43

@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.

bluerider commented on 2013-02-04 22:30

@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.

bluerider commented on 2013-02-04 22:07

@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.

alucryd commented on 2013-02-04 20:16

@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.

bluerider commented on 2013-02-04 19:37

@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.

bluerider commented on 2013-02-04 19:12

@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!

alucryd commented on 2013-02-04 18:01

@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!

bluerider commented on 2013-02-04 16:17

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

bluerider commented on 2013-02-04 16:09

@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.

alucryd commented on 2013-02-04 11:20

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/

alucryd commented on 2013-02-04 11:17

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/

alucryd commented on 2013-02-04 11:16

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.

alucryd commented on 2013-02-04 09:14

@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.

alucryd commented on 2013-02-04 09:11

@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.

bluerider commented on 2013-02-03 23:32

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]

bluerider commented on 2013-02-03 23:29

@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

alucryd commented on 2013-02-03 22:19

@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.

bluerider commented on 2013-02-03 20:40

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.

bluerider commented on 2013-02-03 20:39

Problem still persisted after downgrading intel driver.

bluerider commented on 2013-02-03 20:21

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.

alucryd commented on 2013-02-02 17:35

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

alucryd commented on 2013-01-31 14:13

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

alucryd commented on 2013-01-27 09:20

Adopting, I'll try to update it today.

Anonymous comment on 2013-01-27 05:47

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

bluerider commented on 2013-01-27 04:09

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.

alucryd commented on 2013-01-08 09:16

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.

Schala commented on 2013-01-08 05:36

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.

alucryd commented on 2013-01-01 19:34

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.

alucryd commented on 2012-12-10 19:08

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.

breed808 commented on 2012-11-22 05:18

Package needs lzo2 as a dependency

jvalecillos commented on 2012-09-15 12:57

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

n23orsk commented on 2012-05-26 22:29

Seems like it requires some portaudio and openal

Anonymous comment on 2012-04-30 13:47

Cmake was fixed.

chenxiaolong commented on 2012-04-24 17:22

@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 :(

alucryd commented on 2012-04-24 07:36

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.

alucryd commented on 2012-04-24 07:25

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

TomBoshoven commented on 2012-04-21 11:24

Thanks for the explanation chenxiaolong. That makes sense.

chenxiaolong commented on 2012-04-21 04:23

@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

Anonymous comment on 2012-04-21 03:54

@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.

chenxiaolong commented on 2012-04-20 14:36

@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 :)

TomBoshoven commented on 2012-04-20 13:31

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.

TomBoshoven commented on 2012-04-20 13:07

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.

TomBoshoven commented on 2012-04-20 12:23

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)

Anonymous comment on 2012-04-20 11:21

@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.

alucryd commented on 2012-04-20 10:12

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.

Anonymous comment on 2012-04-09 10:06

@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.

akspecs commented on 2012-04-09 08:51

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.

Anonymous comment on 2012-04-09 05:26

@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.

akspecs commented on 2012-04-09 03:47

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.

akspecs commented on 2012-04-09 03:46

/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.

alucryd commented on 2012-03-09 20:05

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

alucryd commented on 2012-03-09 19:54

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?

Anonymous comment on 2012-03-09 01:35

@Amarus
Exactly.

Anonymous comment on 2012-03-08 13:59

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.

TomBoshoven commented on 2012-03-08 13:05

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

Anonymous comment on 2012-03-08 01:34

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.

Anonymous comment on 2012-03-07 21:59

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

neXyon commented on 2012-03-07 20:23

Still not working. :-(

Anonymous comment on 2012-03-07 09:57

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

neXyon commented on 2012-03-07 09:01

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

chenxiaolong commented on 2012-03-05 23:00

@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?

Anonymous comment on 2012-03-04 08:43

@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.

chenxiaolong commented on 2012-03-04 07:26

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

export CFLAGS="${CFLAGS} -fpermissive"

Anonymous comment on 2012-03-04 04:57

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

export CXXFLAGS="${CXXFLAGS} -fpermissive"

Uninstalling bluez fixed it for me though.

Anonymous comment on 2012-03-04 03:43

@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.

Anonymous comment on 2012-03-04 00:22

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

chenxiaolong commented on 2012-03-02 16:24

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)

Anonymous comment on 2012-03-02 07:16

@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……

chenxiaolong commented on 2012-03-02 05:55

@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 :)

Anonymous comment on 2012-03-02 02:22

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.

chenxiaolong commented on 2012-03-01 18:29

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"

Anonymous comment on 2012-03-01 10:10

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

Anonymous comment on 2012-01-16 02:44

updated

Anonymous comment on 2012-01-15 05:37

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

peacememories commented on 2012-01-13 20:36

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?)

peacememories commented on 2012-01-13 20:10

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!

Anonymous comment on 2012-01-09 00:24

works well

Anonymous comment on 2011-12-10 09:49

@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.

chenxiaolong commented on 2011-12-09 01:14

-> 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 :)

kiodo1981 commented on 2011-12-08 19:39

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

kiodo1981 commented on 2011-12-08 19:39

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

kiodo1981 commented on 2011-12-08 19:26

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

kiodo1981 commented on 2011-12-08 19:21

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

chenxiaolong commented on 2011-12-08 19:11

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.

chenxiaolong commented on 2011-12-08 18:44

@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
).

chenxiaolong commented on 2011-12-08 18:42

@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

kiodo1981 commented on 2011-12-08 09:10

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.

Anonymous comment on 2011-10-22 14:16

Updated PKGBUILD

Anonymous comment on 2011-10-17 11:20

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

kiodo1981 commented on 2011-10-11 09:11

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

kiodo1981 commented on 2011-10-10 11:57

You must install portaudio to start the emulator.

Anonymous comment on 2011-09-11 11:45

@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.

Huulivoide commented on 2011-09-06 20:43

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} .....

Anonymous comment on 2011-09-06 16:22

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

Anonymous comment on 2011-08-23 08:25

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.

chenxiaolong commented on 2011-08-22 00:39

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

Anonymous comment on 2011-08-21 13:31

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.

chenxiaolong commented on 2011-08-20 16:36

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.

Anonymous comment on 2011-08-20 13:36

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