apt-get install libavcodec58 libavcodec58-dev
Extra step due to Symlink bug in Ubuntu’s ffmpeg package. Introduced in 18.04 and persists through (including) 19.04.
apt-get install build-essential libc++-dev cmake
optionally apt-get install clang
apt install git
Get Citra: git clone --recursive https://github.com/citra-emu/citra
Configure build: mkdir citra/build && cd citra/build
If using gcc: cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_FFMPEG=ON ..
if using clang: cmake -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_FLAGS="-O2 -g " \ -DCMAKE_BUILD_TYPE=Release \ -DENABLE_FFMPEG=ON ..
j4 refers to number of build jobs / threads to utilize in building, the more your CPU can support the faster the build time. Mine is 4.
Run the binary directly: cd bin ./citra-qt
[Optional] Install it (you may have to use sudo): make install
This is optional, also since Citra is not a stable release yet. It’s good enough to run and play some of the tested and compatible games but not all.
So you may choose to run it from the citra/build/bin directory or install it
There are certain headers it fails to find without loss of functions it seems but in CMake nonetheless:
-- Looking for pthread_create - not found
-- Looking for include file AudioUnit/AudioUnit.h - not found
-- Looking for include file jack/jack.h - not found
-- Looking for include file audioclient.h - not found
-- Looking for include files windows.h, mmsystem.h - not found
-- Looking for include file SLES/OpenSLES.h - not found
-- Looking for include file android/log.h - not found
-- Looking for include file kai.h - not found
-- Looking for strlcat - not found
-- Looking for strlcpy - not found
-- Looking for arc4random_buf - not found
-- Looking for arc4random_uniform - not found
-- Looking for timingsafe_bcmp - not found
-- Looking for timingsafe_memcmp - not found
Any Clarification in regards to these would be appreciated. Thanks in advanced.
My System Information:
CPU: Intel 6th Gen i5 - 6200U (skylake)
GPU: Nvidia GeForce 940mx (GM108M)
RAM: 8 GB DDR4
OS: Pop_OS (Ubuntu 19.04 Disco Dingo Derivative) with GNOME DE
If you’ve made new findings that are helpful for the build process, then making the changes to the wiki would be appreciated. It’s editable by anyone with a GitHub account, and will be updated with the site eventually.
On the original wiki page, these apt-get commands are the way they are for a reason, they’re separated in a way that the reader can clearly see the different dependencies they’re installing. This is useful, say, if you wanted to build the Qt frontend but not SDL, then you wouldn’t install the packages under the “SDL2” header there. For a build guide, you should either have that logical grouping of packages, or just combine the commands into one if you aren’t interested in that level of granularity.
You’re probably fine. CMake, configure, and the make always fail to find some things, because they check for a lot of different possible setups that will be compiled on.
There are 3 steps of difference from the original provided on the wiki.
libqt5multimedia5-plugins as a dependency for Camera to work (possibly only non-KDE Ubuntu systems). The person who helped me resolve this issues did the edit on the wiki already. Thanks for pointing it out though.
The other dependency issue is of ffmpeg for HLE audio, this is a Distro specific issue (particularly Ubuntu).
The other difference is removal of -stdlib=libc++ flag from -DCMAKE_CXX_FLAGS which makes clang use system default instead. Which in case of Ubuntu is fine, I think. This is only required if you’re picking clang as your compiler. Although -g flag can also be excluded when compiling for RELEASE but I’ve included it for later debugging in case I encounter further problems or ask for help.
I’ll do these corrections, but the particular example you gave is hard to wrap my head around as SDL2 is used for input handling, controller as well as mouse & keyboard for the games & possibly other things(AFAIK). While QT is used for the GUI front-end. ~If there is a way to get a non-QT and SDL2 only front-end then please help me with the compilation so that I may check it out. It would be quite convenient to be able to cut a few dependencies.~
So I checked and as it turns out It compiles both when you’ve got both SDL2 and QT by default. ./citra for SDL2 version and ./citra-qt for QT version. Although ./citra operates like CLI program so you have to give it the ROM path to play it, while configurations need to be copy pasted from the .ini file or configured through the QT interface which seems rather roundabout but I also realise most people would just be more comfortable to use QT which is a cross-platform front-end.
QT is also used for Camera but I don’t know how Citra accesses the camera without QT, or is it just one possible interface for it?
So the way I understand it is SDL2 is required but QT is an optional dependency for a front-end, is that correct?
Please correct me if I’m wrong, thanks
I see but are those checks for optimization of the build then? I mean they must serve some purpose? I realize some of them are probably platform specific or something (I didn’t know Citra supported any other architecture than x86_64 aka amd64)
The first two look good. The third one, I’m personally not really sure whether or not that should be there.
That is correct. The reason that the SDL2 frontend is there isn’t really for any kind of end user reason, we always recommend that users use the Qt interface (although I’ve heard of some people using the SDL2 interface for their Steam shortcuts). The real reason why the SDL2 frontend is maintained is to ensure that the core emulation code, the backend, is properly abstracted. This is good for code quality, and if one wanted to reuse the emulator core with a new frontend (e.g. Android).
I just checked and yeah, since SDL is used for input in both frontend, this seems to be the case.
I believe it is tied to Qt, yes. Summoning @jroweboy as he might have a better answer.
I doubt that they would make the build more or less optimized, it really is a platform and distro specific thing. An exception to this I know of though is that I believe, when compiling on Windows, the MSVC libraries/headers are faster than the alternative MingW32(or perhaps the opposite).
Yeah, I understand why. relying on system default may be error prone. I had to do this because of possible symlink error (similar to ffmpeg) I think but haven’t found the exact issue yet. I opened an issue (on github, same username as here) where I mentioned this.
Nice although 64-bit instruction set on ARM is still new on Android, I think.
Ok, well certainly that makes sense. Such as not finding NEON support (It doesn’t actually look for this, I’m just using this as an example of a platform specific dependency) on a x86_64 (aka amd64) machine but getting it on say Raspberry Pi or another ARM based machine. Although knowing which library is for what would’ve been nice. Especially in the wiki for people looking to contribute on github (maybe?)