Building Dolphin on Debian Stable: problems!

0 users browsing Emulation. | 8 bots

Main » Emulation » Building Dolphin on Debian Stable: problems!

Pages: 1

tomman

Posted on 19-04-28, 22:10 (revision 1)

Dinosaur

Post: #273 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

I decided it was that time of the year where I have to update my local Dolphin build, for the few GC/Wii games I don't play anymore. Last time I successfully did it was in January 21th (commit 3627ef8a0489765eb10ab29a7988866b52493239 according to the .DEB version as packaged by cpack). Aside of having to install a newer Qt5 version than the one available on Stretch (thankfully Qt does offer a GUI-based installer for that - just stash it somewhere in /opt and you're golden), it builds and works just fine with only stock Debian stable packages.

Today... I'm getting this vomit:

[ 64%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp: In member function ‘void WiimoteEmu::CameraLogic::Update(const Common::Matrix44&, bool)’:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:36: error: call to non-constexpr function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’
   std::array<CameraPoint, leds.size()> camera_points;
                           ~~~~~~~~~^~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Common/ChunkFile.h:16:0,
                 from /home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.h:7,
                 from /home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:5:
/usr/include/c++/6/array:171:7: note: ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’ is not usable as a constexpr function because:
       size() const noexcept { return _Nm; }
       ^~~~
/usr/include/c++/6/array:171:7: error: enclosing class of constexpr non-static member function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’ is not a literal type
/usr/include/c++/6/array:90:12: note: ‘std::array<Common::TVec3<float>, 2ul>’ is not literal because:
     struct array
            ^~~~~
/usr/include/c++/6/array:106:56: note:   non-static data member ‘std::array<Common::TVec3<float>, 2ul>::_M_elems’ has non-literal type
       typename _AT_Type::_Type                         _M_elems;
                                                        ^~~~~~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:36: error: call to non-constexpr function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’
   std::array<CameraPoint, leds.size()> camera_points;
                           ~~~~~~~~~^~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:38: note: in template argument for type ‘long unsigned int’ 
   std::array<CameraPoint, leds.size()> camera_points;
                                      ^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:107:58: error: request for member ‘begin’ in ‘camera_points’, which is of non-class type ‘int’
   std::transform(leds.begin(), leds.end(), camera_points.begin(), [&](auto& v) {
                                                          ^~~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:137:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
       for (std::size_t i = 0; i != camera_points.size() / 2; ++i)
                                                  ^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:141:45: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
         const auto& p1 = camera_points[i * 2];
                                             ^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:147:49: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
         const auto& p2 = camera_points[i * 2 + 1];
                                                 ^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:157:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
       for (std::size_t i = 0; i != camera_points.size(); ++i)
                                                  ^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:159:40: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
         const auto& p = camera_points[i];
                                        ^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:178:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
       for (std::size_t i = 0; i != camera_points.size(); ++i)
                                                  ^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:180:40: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
         const auto& p = camera_points[i];
                                        ^
Source/Core/Core/CMakeFiles/core.dir/build.make:1830: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o'
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o] Error 1
make[2]: *** Se espera a que terminen otras tareas....
CMakeFiles/Makefile2:1099: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/all'
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Looks like the GCC version on Debian stable (6.3) doesn't like something, and compilation dies there. Fun.

The offending commit seens to be this one, although if I revert to the commit just prior to that, GCC dies with an internal compiler error (!!!!). Does anyone well versed in C++ and GCC know what the hell is happening here?
I HOPE the answer is not "upgrade your GCC you dummy~" (in fact Dolphin wiki doesn't even recommend any specific GCC version for building, but then the dependencies list hasn't been updated in ages), as this would lead me to two paths I'm actively trying to avoid right now:
- Move to Debian Buster/testing: it has GCC7 and 8, but I'm not upgrading to it yet. Maybe later this year, after it becomes "stable". MAYBE.
- Build GCC from source. Been there, done that, and said "nope, my Fedora Core 6 era is long gone NEVAR AGAIN!"

YES I KNOW that this isn't the Dolphin bugtracker/forum, but I decided to give it a shot here first before tinkering more and filing a issue/ticket or whatever on their bugtrackers.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis	Posted on 19-04-29, 01:01 Hi.
Stirrer of Shit Post: #224 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days	You could always try building with clang, it supposedly has slightly clearer error messages. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-04-29, 04:35

Dinosaur

Post: #274 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Before getting interrupted by the daily "rolling" blackout (and subsequent loss of connection), I managed to have this interaction over the Dolphin IRC channel:

[18:29]       tomman  hi there
[18:29]   tomman  what's the current required GCC version for building Dolphin from source?
[18:30]  tomman  I'm having some trouble with GCC 6.3 (the one from the current Debian Stable)
[18:31]  Billiard        cmake should warn you if you don't meet the reqs
[18:31]   Billiard        what error are you getting?
[18:33]        tomman  https://gist.github.com/dilworks/a7a0e4aafcf072328f6f5019a8bfb58d
[18:33]      tomman  Last time I successfully built Dolphin on Debian stable was like 3 months ago
[18:34]      tomman  (aside of having to install a newer Qt5 release, everything else works with stock packages, or using the internal libraries)
[18:36]   tomman  I get no warnings this time
[18:36]        tomman  (no warnings from cmake, that is)
[18:36]      Billiard        stdlib looks broken if std::array::size is not constexpr
[18:38]   Billiard        actually my usage of .size9) there might be questionable..
[18:43]     Billiard        naw. looks like a gcc and/or stdlib bug
[18:46]    Billiard        tomman: you could try clang if upgrading gcc is not feasible
[18:48]   Billiard        tomman: or you could hack fix that line of code
[18:49]        Billiard        just change leds.size() to 2

Hmmm, I wasn't aware you could now use clang for building Dolphin, so I'll figure it out later.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman

Posted on 19-04-29, 15:24 (revision 3)

Dinosaur

Post: #275 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Switching compilers require to start over with a new build directory, so I setup a separate directory for building with Clang.

Hello brick wall:

[ 15%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Common/GL/GLInterface/EGL.cpp:292:10: error: no viable conversion from returned value of type
      'unique_ptr<GLContextEGL>' to function return type 'unique_ptr<GLContext>'
  return new_context;
         ^~~~~~~~~~~
/usr/include/c++/v1/memory:2459:29: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from
      'std::unique_ptr<GLContextEGL>' to 'const std::__1::unique_ptr<GLContext, std::__1::default_delete<GLContext> > &' for 1st argument
class _LIBCPP_TYPE_VIS_ONLY unique_ptr
                            ^
/usr/include/c++/v1/memory:2488:49: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to
      'nullptr_t' for 1st argument
    _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR unique_ptr(nullptr_t) _NOEXCEPT
                                                ^
/usr/include/c++/v1/memory:2515:31: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to
      'std::__1::unique_ptr<GLContext, std::__1::default_delete<GLContext> > &&' for 1st argument
    _LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT
                              ^
/usr/include/c++/v1/memory:2519:9: note: candidate constructor [with _Up = GLContextEGL, _Ep = std::__1::default_delete<GLContextEGL>] not
      viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to 'unique_ptr<GLContextEGL, std::__1::default_delete<GLContextEGL> > &&'
      for 1st argument
        unique_ptr(unique_ptr<_Up, _Ep>&& __u,
        ^
/usr/include/c++/v1/memory:2534:35: note: candidate template ignored: could not match 'auto_ptr' against 'unique_ptr'
        _LIBCPP_INLINE_VISIBILITY unique_ptr(auto_ptr<_Up>&& __p,
                                  ^
1 error generated.
Source/Core/Common/CMakeFiles/common.dir/build.make:777: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o'
make[2]: *** [Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o] Error 1
CMakeFiles/Makefile2:1006: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/common.dir/all'
make[1]: *** [Source/Core/Common/CMakeFiles/common.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Stretch's clang (3.8) is ancient, as expected. Luckily there are newer versions through backports, so let's try that. The latest one is clang-6.0, so let's go with it:

[ 12%] Building CXX object Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/AudioCommon/AudioCommon.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/ConfigManager.h:17:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/TitleDatabase.h:8:
In file included from /usr/include/c++/v1/unordered_map:350:
/usr/include/c++/v1/__hash_table:1169:43: error: conflicting types for '__hash_table<_Tp, _Hash, _Equal, _Alloc>'
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table()
                                          ^
/usr/include/c++/v1/__hash_table:856:5: note: previous declaration is here
    __hash_table()
    ^
/usr/include/c++/v1/__hash_table:1237:43: error: conflicting types for '__hash_table<_Tp, _Hash, _Equal, _Alloc>'
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(__hash_table&& __u)
                                          ^
/usr/include/c++/v1/__hash_table:870:5: note: previous declaration is here
    __hash_table(__hash_table&& __u)
    ^
2 errors generated.
Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/build.make:62: fallo en las instrucciones para el objetivo 'Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o'
make[2]: *** [Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o] Error 1
CMakeFiles/Makefile2:949: fallo en las instrucciones para el objetivo 'Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/all'
make[1]: *** [Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

...nope. Lovely compiler error messages.
(Updating libc++-dev is not an option: there are no backported versions for Stretch, and on Buster, the Debian packagers changed the packaging structure a bit: this one no longer comes from a standalone source package, but from llvm-toolchain itself)

Anyway, let's go back to GCC. I decided to start over with a clean build directory, just in case. Let's redo the failing build without applying any hacks:

[ 64%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteReal/WiimoteReal.cpp: In member function ‘bool WiimoteReal::Wiimote::CheckForButtonPress()’:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteReal/WiimoteReal.cpp:385:29: internal compiler error: in process_init_constructor_union, at cp/typeck2.c:1555
       ButtonData buttons = {};
                             ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
Source/Core/Core/CMakeFiles/core.dir/build.make:2012: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o'
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o] Error 1
CMakeFiles/Makefile2:1099: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/all'
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

What. The. FUCK!?

~~Not only the original code is compiling fine WITHOUT ANY MODIFICATIONS, the compiler now dies with an ICE when parsing an... empty array.~~ Apparently I had not properly reset the repository to the latest commits. After playing some git command enchantments, I'm now at the tip of the head of master (i.e. the latest commit). I still need to apply Billiard's hack... and seconds later, GCC still dies with the exact same ICE (ButtonData is actually an union, not an array).

I guess I've just found something I hate more than smartdevices: C.

Ah well, I suppose all paths eventually lead to the same outcome: "update your distro, buddy~".

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Duck Penis

Posted on 19-04-29, 17:04

Stirrer of Shit
Post: #227 of 717
Since: 01-26-19

Last post: 1763 days
Last view: 1761 days

Posted by tomman
I guess I've just found something I hate more than smartdevices: C.

Ah well, I suppose all paths eventually lead to the same outcome: "update your distro, buddy~".

That's C++'s infamous template vomit, C has nothing to do with this.

I guess your options are downloading a statically linked GCC/clang (doesn't exist), downloading and unpacking a newer release's version of GCC/clang and praying there aren't any new dependencies (good luck), or biting the bullet and compiling one. Buildroot should make things smoother, in theory. I used it for something (musl?) and it worked fine.

And you've checked all the spooky stuff (memtest, corrupted compiler, corrupted source files) that "shouldn't happen"?

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

tomman

Posted on 19-04-29, 18:09

Dinosaur

Post: #276 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

My best bet -right now, short of upgrading my distro or building GCC from source- would be to figure out how to install GCC 8 .DEBs from Buster on Stretch.

...after looking at the respective source and binary package lists, looks like if I want the newer clang 7, I would also need to pick some GCC 8 dependencies.

In the case of GCC, things doesn't look THAT bad: traditionally older GCC versions keep working fine with newer Debian releases (in fact you usually have to end purging your old GCC versions after a successful dist-upgrade), and there are documented cases of people pulling GCC .DEBs from testing down to stable without secondary effects. The only problem with GCC is the sheer number of packages provided by its source package you may need for a base install. Mixing stable with testing is never a good idea, aside of very specific cases.

To make it clear: I WILL eventually update this laptop to Buster, but after enduring the breakages train of the two prior Debian releases during Testing, I had decided this time to stay away from the kitchen while Buster brews its way into Stable.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman

Posted on 19-04-29, 19:46 (revision 1)

Dinosaur

Post: #277 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Decided to give another try to clang-3.8 after finding a workaround here: https://stackoverflow.com/questions/32742741/clang-error-with-stdunique-ptr

Now the brick wall du jour is this:

[ 23%] Linking CXX executable ../../../Binaries/traversal_server
/usr/bin/ld: CMakeFiles/common.dir/Random.cpp.o: referencia sin definir al símbolo '__cxa_thread_atexit@@CXXABI_1.3.7'
//usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Source/Core/Common/CMakeFiles/traversal_server.dir/build.make:94: fallo en las instrucciones para el objetivo 'Binaries/traversal_server'
make[2]: *** [Binaries/traversal_server] Error 1
CMakeFiles/Makefile2:971: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/traversal_server.dir/all'
make[1]: *** [Source/Core/Common/CMakeFiles/traversal_server.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Oh joy, a LINKER error.

Tried adding -lstdc++ to LDFLAGS/CMAKE_whatever_LINKER_FLAGS, without avail.

FUN FUN FUN.

UPDATE: Replacing "-stdlib=libc++" with "-stdlib=libstdc++" and switching -lc++ with -lstdc++ fixes this.

BUT! Now build dies near the end:

[ 80%] Building CXX object Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/Device.h:14:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/IOS.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/IOSC.h:16:
/home/tomman/workbench/dolphin-emu/Source/Core/Common/Crypto/ec.h:11:17: warning: nested namespace definition is a C++1z extension; define each
      namespace separately [-Wc++1z-extensions]
namespace Common::ec
                ^~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:19:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/Device.h:16:14: warning: nested namespace definition is a C++1z extension; define each
      namespace separately [-Wc++1z-extensions]
namespace IOS::HLE
             ^~~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:27:14: warning: nested namespace definition is a C++1z extension; define
      each namespace separately [-Wc++1z-extensions]
namespace HLE::FS
             ^~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:20:
/home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/VolumeVerifier.h:32:14: warning: nested namespace definition is a C++1z extension; define
      each namespace separately [-Wc++1z-extensions]
namespace IOS::ES
             ^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:77:15: error: cannot refer to class template 'pair' without a
      template argument list
  return std::pair(checkbox, line_edit);
         ~~~~~^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_pair.h:194:12: note: template is declared here
    struct pair
           ^
/home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:130:13: warning: enumeration value 'None' not handled in switch
      [-Wswitch]
    switch (problem.severity)
            ^
5 warnings and 1 error generated.
Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/build.make:1127: fallo en las instrucciones para el objetivo 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o'
make[2]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o] Error 1
CMakeFiles/Makefile2:1763: fallo en las instrucciones para el objetivo 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/all'
make[1]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Awesomest. I love you too, C++.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman

Posted on 19-04-29, 21:27

Dinosaur

Post: #278 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

FLAWLESS VICTORY

Step 1) Use this patch: https://gist.github.com/dilworks/6dd7caf8d70d46e98ba39dd808a66b05
Step 2) Invoke cmake with:

CC=clang CXX=clang++ CXXFLAGS+=-stdlib=libstdc++ LDFLAGS+=-lstdc++ cmake -DCMAKE_PREFIX_PATH=/opt/Qt/5.11.1/gcc_64/ ..

(adjust your Qt5 directory accordingly to your setup)
Step 3) make
Step 4) Go play videogames

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Kawaoneechan	Posted on 19-04-29, 23:14 Hi.
The best thing since bread glue Post: #209 of 599 Since: 10-29-18 Last post: 195 days Last view: 3 hours	🎉 Yaaaaay! 🎊

CaptainJistuce	Posted on 19-04-29, 23:23 Hi.
Custom title here Post: #419 of 1164 Since: 10-30-18 Last post: 63 days Last view: 8 hours	Also, Muramasa is an excellent choice. --- In UTF-16, where available. ---

tomman

Posted on 19-04-30, 16:27

Dinosaur

Post: #281 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Muramasa was the very reason of why I got into Wii/GC emulation, and that's only because I played it on a roommate's Wii back at my college dorm era.

I really loved the game. But... it was a Wii exclusive.

But that was at mid '10. There was this promising GameCube emulator named "Dolphin", and the rage at the time was its just-implemented Wii emulation. Not many games ran, and unfortunately Muramasa was one of those that were unplayable beyond a certain point (that I never reached back then), plus it was plagued with graphic glitches all the way. But hey, there was I, sending patches to the Dolphin team because keyboard input on X11 was a mess back then ("I came to play Muramasa: The Demon Blade, not Hackamasa: the X11Input Blade!"). My name is referenced in a lone commit that has been long buried with the years elapsed since then.

And yes, Dolphin ran at a respectable 60% with Muramasa on my T5500 with the proprietary ATi blob back then (nowadays Dolphin wouldn't even boot on such a setup). Muramasa was actually PLAYABLE, albeit laggy at times. I didn't cared, I was playing that damn good game on my laptop, back when the Wii was still a hot seller! I even bought a real Wiimote solely for that game! (although I ended using it for Zelda OoT not long after that)

Years later I would finish the game once with Momohime on my Steamlaptop, this time at a solid 60FPS all the way, albeit with minor graphic glitches that have been fixed since then.

I still wish Muramasa would get a PC port someday. Back then, a good friend of mine (the owner of the Wii where I played the very same PAL rip of the game I play today on Dolphin, solely because it was actually localized to Spanish... unlike the NTSC-U version) told me that "butbutbut Nintendo paid for the exclusive!!!". Years later, it got a enhanced Vita port out of nowhere. But then, the Vita is dead, and it is not a PC.
Come on, Marvelous! It would sell like hotcakes on Steam, just ask Bayonetta!

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman

Posted on 19-05-17, 02:09

Dinosaur

Post: #325 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

PSA: As of 2019/05/05, with the merge of this pull request, Dolphin is no longer buildable with GCC under Debian Stretch anymore.

You need a C++17 compiler, period. Clang 3.8 does implement some features, but for full support you need Clang 5.0 at the very least. Dunno if Dolphin is still buildable with Clang 3.8, the answer seems to be "ask me later"...

tl;dr: time to update your distro, buddy~

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Wowfunhappy	Posted on 19-08-01, 00:39 Hi.
Post: #8 of 21 Since: 11-08-18 Last post: 1254 days Last view: 1254 days	Why are you building Dolphin yourself anyway? It doesn't sound like you're making any source code changes?

tomman

Posted on 19-08-01, 00:59

Dinosaur

Post: #463 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Posted by Wowfunhappy
Why are you building Dolphin yourself anyway? It doesn't sound like you're making any source code changes?

Because...

- I can
- I want
- The binaries on Debian repos are hopelessly outdated (they're from the last stable release, which was years ago!)
- There are no repositories compatible with Debian which ship development builds (the ones you actually WANT to run if you actually care about playing videogames). No, you can't use Ubuntu PPAs with Debian. Not unless you want problems
- I have no other options, after having exposed the last two points

Anyway, once I upgrade to Debian Buster, I should be able to build it out of the box, no need to bring 3rd-party Qt installers or mess with patches to please "outdated" compilers.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Wowfunhappy

Posted on 19-08-01, 01:35 (revision 2)

Post: #10 of 21
Since: 11-08-18

Last post: 1254 days
Last view: 1254 days

Posted by tomman

- I can
- I want

If those are the primary reasons, great! It just didn't sound like you were enjoying yourself all that much. :P

Posted by tomman

- The binaries on Debian repos are hopelessly outdated (they're from the last stable release, which was years ago!)
- There are no repositories compatible with Debian which ship development builds (the ones you actually WANT to run if you actually care about playing videogames). No, you can't use Ubuntu PPAs with Debian. Not unless you want problems
- I have no other options, after having exposed the last two points

...on a scale of 1–10, how much would you hate me if I suggested using Flatpak?

tomman

Posted on 19-08-01, 02:25

Dinosaur

Post: #465 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

Posted by Wowfunhappy
...on a scale of 1–10, how much would you hate me if I suggested using Flatpak?

NaN

I have nothing against flatpaks/snaps (they do help solving a real problem on the distribution of off-repo/third-party/proprietary software under Linux), but I'm not really interested. My only experience was with an Avidemux flatpak (or was it an "snap"? God, those hipsters can't get their shit together), and... it crashed on an ordinary Debian. I ended compiling Avidemux anyway.

And in the case of emulators, there are good reasons for building your own binaries, anyway: -march=native is one, ensuring that your binary will play nice with the libs provided by your distro is another, and in rare cases, you might want to play with patches/hacks not (yet) present on their respective development versions, or whatever.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman	Posted on 19-08-24, 20:18 (revision 1) Hi.
Dinosaur Post: #507 of 1315 Since: 10-30-18 Last post: 58 days Last view: 17 hours	UPDATE: I've moved to Buster, and Dolphin now builds out of the box with only stock Debian deps and compilers (it ships with GCC 8.3, Clang 7, and Qt 5.11). So yeah, the answer was "upgrade your distro, buddy" since the very beginning. Buster is still not THAT stale yet, so the advice is still valid. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

tomman

Posted on 22-03-12, 14:47

Dinosaur

Post: #1068 of 1315
Since: 10-30-18

Last post: 58 days
Last view: 17 hours

It's that time of the year again, when Dolphin build errors kindly remind me to not postpone my Debian distro updates for longer:

https://pastebin.com/8VZFxiuP

Last time I managed a successful build under Buster was in the very last day of 2021, but of course that was decades ago. C and friends hate me as much as I hate them, but it also means that GCC 8.3 (the one that ships with Buster) is no longer good for building Dolphin. Since Debian will never offer newer GCC versions via backports, these are my options:

- Build with Clang. Unlike GCC, we DO get newer Clang/LLVM versions via backports, and the newest one there for Buster is Clang 11 which build latest Dolphin just fine. I suggest keeping separate build directories (one for GCC, another for Clang)

- Update your distro. Bullseye ships with GCC 10.2, which is the same used by Dolphin Debian buildbots. But man, I'm laaaaaazy....

- Backport GCC 10+ yourself. Do I look like a bored teenager?

So Clang is it, for now. FWIW, latest Clang seems to be 13, but that's only available on current Testing (Bookworm), and hasn't been backported yet to Bullseye.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™

Pages: 1

Main » Emulation » Building Dolphin on Debian Stable: problems!

bboard