Debian Building Issues

[petabyt]

I can't get past this issue on Debian 10 x64 MATE: Fetch.cpp:(.text+0x1313): undefined reference tostd::filesystem::remove_all(std::filesystem::__cxx11::path const&)'` Here is the full error:

[  0%] Building CXX object CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o
[  0%] Building CXX object CMakeFiles/ospm.dir/ospm_src/Main.cpp.o
[  0%] Building C object CMakeFiles/ospm.dir/ospm_src/dep/miniz.c.o
/home/daniel/Pulled/new-ospgl/ospm_src/dep/miniz.c:3079:9: note: #pragma message: Using fopen, ftello, fseeko, stat() etc. path for file I/O - this path may not support large files.
 #pragma message("Using fopen, ftello, fseeko, stat() etc. path for file I/O - this path may not support large files.")
         ^~~~~~~
[  0%] Linking CXX executable ospm
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `Fetch::fetch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Fetch::OverwriteMode, bool)':
Fetch.cpp:(.text+0x1313): undefined reference to `std::filesystem::remove_all(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: Fetch.cpp:(.text+0x1643): undefined reference to `std::filesystem::create_directories(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::__cxx11::path::path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, std::filesystem::__cxx11::path::format)':
Fetch.cpp:(.text._ZNSt10filesystem7__cxx114pathC2EONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_6formatE[_ZNSt10filesystem7__cxx114pathC5EONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_6formatE]+0x4f): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::exists(std::filesystem::__cxx11::path const&)':
Fetch.cpp:(.text._ZNSt10filesystem6existsERKNS_7__cxx114pathE[_ZNSt10filesystem6existsERKNS_7__cxx114pathE]+0x14): undefined reference to `std::filesystem::status(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::filesystem::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::filesystem::__cxx11::path::format)':
Fetch.cpp:(.text._ZNSt10filesystem7__cxx114pathC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE]+0x64): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ospm.dir/build.make:118: ospm] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/ospm.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Also, I pulled like git clone --recurse-submodules https://github.com/TheOpenSpaceProgram/new-ospgl, and followed the exact instructions in the readme.

[tatjam]

I believe this has to do with the compiler being a relatively old version (older than GCC 9.1). Maybe try to add stdc++fs to the linker flags on CMake, like this:

target_link_libraries(OSPGL fmt liblua-static assimp BulletSoftBody BulletDynamics BulletCollision LinearMath ${CMAKE_DL_LIBS} stdc++fs) (CMakeLists.txt)

You may have to do that too on the ospm target.

This should get it to compile with older versions of gcc, if it works I will add it to the CMake file as I believe it doesn't really hurt newer compilers: https://en.cppreference.com/w/cpp/filesystem (Bottom of the page)

[petabyt]

Yep, that seems to fix it up. I'm now getting this, I guess because of a dependency problem.

[INF] Starting OSP with settings = "settings.toml" and resource path = "./res/"
[renderer]
    type = "windowed"
    scale = 0.75000000000000000
    width = 1366
    height = 768

[INF] Package 'OSP Core 0.0.1' ('core' loaded as 'core')
[INF] Package 'Debug Solar System 0.0.1' ('debug_system' loaded as 'debug_system')
[WRN]   Lacks dependency ''
[INF] Package 'Test Parts 0.0.1' ('test_parts' loaded as 'test_parts')
[INF] Package 'OSP Default Navball 0.0.1' ('default_navball' loaded as 'navball')
[FTL] Could not initialize glad
Raising exception
terminate called after throwing an instance of 'char const*'
Aborted

(By the way, the code for this project was written well, looks good.)

[tatjam]

I pushed a new commit to investigate that GLAD issue, it probably has to do with the OpenGL context creation. I also added the filesystem link on non-windows platforms: https://github.com/TheOpenSpaceProgram/new-ospgl/commit/a0b7cf0d5af4ad2c663e33af2b3af1618ac61bb3

If you run it now it will report a proper error if the problem has to do with OpenGL

I should fix that dependency error, it's not actually any problem, it's just that the debug_system defines one of its dependencies to be " ", which of course is not a valid package!

[petabyt]

What is said:

[ERR] Error initializing GLFW window: GLX: Failed to create context: GLXBadFBConfig
[FTL] Failed to initialize GLFW

[petabyt]

I changed glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4); to glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); And am now getting this:

[INF] Loading package navball
[ERR] Condition 'Invalid package (debug_system) given' failed
terminate called after throwing an instance of 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >'
Aborted

[tatjam]

That must mean that the package debug_system is not present while loading the save-game (Line 34 of VehicleInWorld.cpp). Check that you have it (look into the res/ folder, or re-download it with ospm fetch). Otherwise I have no idea why that's showing up, your previous log files show that the debug_system package is present.

I tested the game with the same change as yours and everything works fine. The planet rendering may have texturing broken (only visible on water, terrain is not textured as of now) if your GPU doesn't support OpenGL 4. It would not be too hard to write a compatibility mode, the only OpenGL 4 feature that is used are vertex attribute bindings to speed up tile rendering a bit by sharing the UV buffer.

[petabyt]

Looking in the res folder, I only see navball and core, and running ./ospm fetch returns:

terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 18446744073709551615) > this->size() (which is 0)
Aborted

Also, my GPU should support OpenGL 4, but I uninstalled all Nvidia drivers (they make my system unstable and are hard to diagnose). I have a Windows 10 installation, but I don't want to install Visual Studio to build it.

[tatjam]

Oh that error shows up because of running ./ospm fetch without an argument. (It's still just a "place-holder" command, so no error handling), these are the commands:

./ospm fetch https://github.com/TheOpenSpaceProgram/new-ospgl/releases/download/ospm-test/debug_system.zip
./ospm fetch https://github.com/TheOpenSpaceProgram/new-ospgl/releases/download/ospm-test/test_parts.zip

Don't worry much about OpenGL 4 as it will probably work fine. Maybe planet rendering doesn't work but it's easy to add some kind of compatibility mode for older graphics cards (and for Macs, I believe they only suport OpenGL 3.3), it's just moving a few vertex buffers around.

If you want to build it on windows on a more "lightweight" tool-set I recommend KDevelop, although you need to install MSVC (just the compiler, the whole Visual Studio download is not needed), you can use MinGW but I have not tested that. I recommend building it on Linux, as the Windows build is a bit more tricky and less "automatic" most of the time.

[petabyt]

Yeah, thanks. It is working fine now. It is showing me a very cool rocket building interface.

[tatjam]

If you want you can check the flight scene by changing line 42 in src/VehicleInWorld.cpp from:

osp.game_state.load_scene(new EditorScene());

to

osp.game_state.load_scene(new FlightScene());

But it may be broken due to the OpenGL version. I will close the issue now but will create a new one to work on OpenGL 3 compatibility.