Rpcs3: Linux: "error: chosen constructor is explicit in copy-initialization"

[mdeguzis]

Getting errors like this:

In file included from /build/rpcs3-0.0.0.9+20160722git+bsos/rpcs3/Emu/RSX/GL/gl_render_targets.h:2:
/build/rpcs3-0.0.0.9+20160722git+bsos/rpcs3/Emu/RSX/GL/../Common/surface_store.h:68:76: error: chosen constructor is explicit in copy-initialization
                std::unordered_map<u32, surface_storage_type> m_render_targets_storage = {};
                                                                                         ^~
/build/rpcs3-0.0.0.9+20160722git+bsos/rpcs3/Emu/RSX/GL/../Common/surface_store.h:77:3: note: in instantiation of default member initializer 'rsx::surface_store<gl_render_target_traits>::m_render_targets_storage' requested here
                surface_store() = default;
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/unordered_map.h:139:7: note: constructor declared here
      unordered_map(size_type __n = 10,

• System: Debian Jessie
• Using: clang/clang++ / llvm-3.9
• Build log: http://sprunge.us/eXWg
• Maybe related: stack overflow

[kd-11]

Does compilation proceed okay if you fix that line? Clang is missing some of the newer proposed c++ features it seems. You might run into constexpr errors later in the build.

[mdeguzis]

Clang is missing some of the newer proposed c++ features it seems

That was my guess, since I thought (maybe I'm wrong) that feature set support in clang is not quite as good as gcc. Unfortunately, gcc is much more difficult to backport, but I could to so manually I've found. As far as your question to fix this line... I'm not an experience programmer, but I could look into that specific error, as did some on stack overflow. I found a manual script to make a cross toolchain gcc into my /opt directory. May try that as well Actually had to patch the debian/rules of llvm 3.8, since they have an error in non-autoconf enabled builds.

[mdeguzis]

Backported LLVM/Clang 3.9, but no luck. I tried using libc++ over libstdc++ (from GNU). See: debian/rules.

Log: http://sprunge.us/eWHU

[danilaml]

Why does it use /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/unordered_map.h? Seems like old gcc lib. We need gcc 5.1 at least.

[mdeguzis]

Idk I'm trying to use clang but I assume that is pulled in from build depends.

[mdeguzis]

g++ should not be used, maybe due to GNU version of libc. I am directing debian/rules not to use libstdc, rather, libc++ (-stdlib=libc++). tr1/type_traits is for libstdc+, but instructed the libc++ flag.

    rm -rf rpcs3/build && mkdir -p rpcs3/build
    cd rpcs3/build && cmake \
            -DCMAKE_BUILD_TYPE='Release' \
            -DCMAKE_CXX_COMPILER=clang++-3.8 \
            -DCMAKE_C_COMPILER=clang-3.8 \
            -DCMAKE_C_FLAGS="-Wall -std=c99" \
            -DCMAKE_CXX_FLAGS="-O2 -g -stdlib=libc++" \
            -DUSE_SYSTEM_LIBPNG='ON' \
            -DUSE_SYSTEM_FFMPEG='ON' \
            -DCMAKE_INSTALL_PREFIX=/usr ..
    make -C rpcs3/build

Log: http://sprunge.us/aTGC

/usr/include/wx-3.0/wx/strvararg.h:30:18: fatal error: 'tr1/type_traits' file not found
        #include <tr1/type_traits>
                 ^
1 error generated.
CMakeFiles/rpcs3.dir/build.make:76: recipe for target 'CMakeFiles/rpcs3.dir/BasicMouseHandler.cpp.o' failed
make[4]: *** [CMakeFiles/rpcs3.dir/BasicMouseHandler.cpp.o] Error 1

I see where type_traits is defined for wx_widgets here. My CMakeCache.txt is here

-- The C compiler identification is Clang 3.9.0
-- The CXX compiler identification is Clang 3.9.0
-- Check for working C compiler: /usr/bin/clang-3.9
-- Check for working C compiler: /usr/bin/clang-3.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++-3.9
-- Check for working CXX compiler: /usr/bin/clang++-3.9 -- works

[AniLeo]

Is this still an issue?
Also llvm-3.9 isn't supported, it requires 3.8 at the moment

[mdeguzis]

Yes this is still an issue. Kinda diverged into #2585 a bit. I backported LLVM 5.0.

[deepbluev7]

You can't use the headers from here.

[mdeguzis]

Well crap then, guess I am up a creek then, unless I go the dirty route of using gcc from a PPA at build time on Debian/SteamOS. I had a bear of a time trying to backport gcc, which obviously is no small task.

[danilaml]

@mdeguzis What do you mean by trying to backport gcc? Can't you use package from sid?

[mdeguzis]

I could try to install it, but i'm fairly sure it needs a lot of deps.

[deepbluev7]

You can't backport gcc. If you compile against the newer headers, you have to ship the newer libstdc++. Also I'm not sure how well that would work in practice, as gcc5 introduced a new ABI. I'd suggest just providing a package for sid and waiting for the next debian release to provide a package for stable users. I think stretch is not that far off and ships gcc-6.3.

[mdeguzis]

.....I am

[deepbluev7]

I think, if you link against clangs libc++, all libs have to be linked against it, but I could be wrong about that. (You can't pass c++ objects between binaries compiled with different stdlibs)

[danilaml]

@mdeguzis ah, sorry. Brainfart xD.

[paulsapps]

why not set up a docker container build env for linux, would surely be easier?

[deepbluev7]

@paulsapps, GCC and libstdc++ are have forward compatible ABIs, but not backward compatible ABIs. That means, sure, you can build it in docker, but you would also have to run it in docker, as you need the newer libstd++. You could also ship the newer libstdc++, but that would be against debian packaging policy. Basically you only have the choice of using a newer distribution or an Appimage/snap/flatpak. Although if there are other ways, I'm happy to be corrected.
Related documentation

[scribam]

@mdeguzis Is this still an issue?
Would it be fine for you to use AppImage (https://rpcs3.net/download)?

[mdeguzis]

I'm not sure that will work with my core target: SteamOS. I will give it a try though soon and see what happens, Unfortunately, Valve has not yet rebased SteamOS on Debian Stretch.

[AniLeo]

Do you have any updates on the status of this - with either AppImage or compiling from Git.

In case it doesn't work, please update the issue anyways.

[hcorion]

Please close this, issue has to do with the outdated build system used and no response was given.