how to build on linux

[pgruenbacher]

I can't seem to find any details on the build steps for linux other than an ubuntu codelite projects.

[OvermindDL1]

It is a bit odd for a modern C++ project not to use cmake nowadays, even Visual Studio supports cmake natively now. :-)

[wolfgangfengel]

what would be a good reason to use cmake? It adds another step to the build process that can fail and it is not supported by most of our target platforms. It is something that shows that a project is built by a single person. You don't want a whole team to spend time on this.

[wolfgangfengel]

@pgruenbacher going back to the original poster: I think we have a description in the Readme ... did you already check this out? It is generally a bit more elaborate to setup a Linux dev environment because you have to make choices on drivers. Please provide a bit more detail what you are missing.

We only support the dev environment described in the Readme. This is what we are testing on Jenkins. If you want to use anything else I can make you part of an internal support group. There are people in there that use other Linux distributions ...

[pgruenbacher]

sorry i found it PRE_BUILD.command. i'm not familiar with command files so didn't recognize.

[OvermindDL1]

what would be a good reason to use cmake?

Well tested framework, handles a lot of things that are having to be handled manually right now and thus are very brittle, among significantly more including the below, etc...

It adds another step to the build process that can fail and it is not supported by most of our target platforms.

What would fail about it? It's the most used C/C++ build system out.

And what target platform does it not support? It has greater compatibility and support than even make itself.

The list of supported platforms of this project is actually extremely tiny of the overall cmake system support. The platforms listed in the readme:

Windows 10 Windows 7 support Linux Android Pie macOS iOS XBOX One / XBOX One X PS4

Are all trivial in cmake, even for cross compilation purposes for all of them short of compiling 'to' macos from another platform (but it can still cross-compile to those as well, just might need a docker image for a quick-setup environment or so, or set it up manually), but all are fully supported first-class build targets for local from all except xbox/ps4/ios which have to be cross-compiled to (because of the target system limitations).

In addition, people would be able to work with this project with any IDE of their choice, not some weird ones like codelite (which I've never heard of before this, that is a very very weird IDE to support in this project when the common linux ones are vi/emacs/KDevelop/IntelliC++), where cmake supports them all, including codelite

It is something that shows that a project is built by a single person. You don't want a whole team to spend time on this.

I'm... not actually sure what this is referencing so don't know how to comment on it... ^.^;

---

I found this project very recently linked from EnTT, so let's give a try building it, see if this might be useful documentation for others to skip a lot of this work:

Just as someone new to looking at this project but significantly not new to C++ in general for over 25 years (and over 30 years for C) I have no clue how to compile it. There is no Makefile, no ninja definition file, no CMakeList.txt file, there is nothing that is even remotely standard for being able to build this project, not even an INSTALL or COMPILE or so instruction file for how to do so as is standard.

The README.md states to run PRE_BUILD.command, but the only thing that file seems to do is curl down a zip file of art assets (which is something cmake itself should be doing as it sets up the environment, not some weird shell script that is for some reason bound to /bin/bash instead of a standard /bin/sh posix shell link, even though it's not using any bash'ism, so it won't work on systems that don't have bash unless the user edits it). And very weirdly, the executable flag for the PRE_BUILD.command file isn't even set it on it the git repo itself, forcing the user to execute it either via bash directly or calling chmod +x on it, which of course would desync it from the git repository as it is then an edited file.

Further reading of the README.md and I'm having issues finding out how to compile this. It uses no build system that I can see so I can only guess it is something custom but if so then it doesn't seem to be documented in the git repo at all.

So at this point I look in the travis file to see what travis is doing, and this is the most sparse travis file I've ever seen. ^.^

First, the travis file only seems to run on osx, so the supposed linux support seems untested, and even then the osx runner is just executing a python file (python in a C++ project?!). Looking in this python file, it is using very non-standard python naming conventions and emacs is yelling at me because it is failing more lint tests than I've seen in a long time, this file needs a go-over for sure.

Hmm, apparently the .gitignore file contains some lines that belong to the global gitignore listing rather than a project one as well the linter is also telling me, and I quite agree with it, definitely some lines that don't belong.

On the python file though, let's see what it does to figure out how to build this on linux, first let's just try running it after telling it to ignore all the lint failures:

/bin/sh: ./PyBuild.py: Permission denied

Oh right, the git project is not setup correctly to set the executable bit...

Oy, downloading the art from the server is sooo slow, only around 25.8m/second (I'm using a fresh container for this as I have no clue what the python file will do and it's way dense with a lot of non-build-related-scaffolding to be able to read it clearly right now) and it should be a lot faster than that...

  File "./PyBuild.py", line 154
    print "Killed Application. Something went wrong with the app, it was idle for too long."
                                                                                           ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Killed Application. Something went wrong with the app, it was idle for too long.")?

Wait what? Is this a Python2 file? I don't even have python2 on this system it's such an old python version now!

Blah, grabbing another repo to add in, adding python2 to the container, rebuilding everything (which is mostly waiting on the art file to download again) since the dependencies changed... And done... I'd highly highly recommend not using python2 considering it hasn't had any updates in years and is old enough that it is being actively removed from many repositories now, python3 is the only thing that should be used nowadays (or for the past 10-15 years now really)...

Also, the rm: can't remove 'Art.zip': No such file or directory printing out on stderr is really polluting of the log considering that something printing out there automatically marks this build as failed so I have to override that, you should only delete the file if it already exists (basically add [ -f ./Art.zip ] && or so before the rm).

# ... snip a whole *TON* of stuff ...
The command '/bin/sh -c python2 ./PyBuild.py' returned a non-zero code: 255

Well... this is fun... let's start at the top of that output:

/The-Forge
make: *** No targets specified and no makefile found.  Stop.
make: *** No targets specified and no makefile found.  Stop.

Ahh, so Makefiles do exist somewhere! Let's find them:

╰─➤  find . -name Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/BulletCollision/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/BulletDynamics/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/LinearMath/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/ppu/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/ppu/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/common/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/spu/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/spu/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/software_cache/cache/include/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/vectormathlibrary/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/vectormathlibrary/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Demos/CellSpuDemo/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Demos/OpenGL/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.82/Extras/CDTestFramework/AntTweakBar/src/Makefile
./Common_3/ThirdParty/OpenSource/SPIRV_Cross/Makefile
./Common_3/ThirdParty/OpenSource/SPIRV_Cross/samples/cpp/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/linux/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/linux/contrib/zlib/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/contrib/gtest/make/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/contrib/gtest/scripts/test/Makefile
./Common_3/ThirdParty/OpenSource/lua-5.3.5/src/Makefile
./Common_3/ThirdParty/OpenSource/lua-5.3.5/Makefile
./Common_3/ThirdParty/OpenSource/hlslparser/Makefile
./Common_3/ThirdParty/OpenSource/gainput/Ubuntu/Makefile
./Common_3/ThirdParty/OpenSource/gainput/Ubuntu/lib/Makefile

Uh, so I'm guessing something here is failing to build, but the make output is not detailing 'what' that is considering No targets specified and no makefile found. I'm not finding anything that looks like a log file either, or even an out-of-source build directory either? Hmm, think it's time to delve more into this python file (why does this file exist in a C++ project...)...

Well I was starting to copy/paste code here while commenting on it but it quickly become obvious that this is a build script in python form that I can't even tell if it does any form of caching or dependency management that isn't manual or anything, and there's stuff here about XML files too? And it looks like it is trying to execute something called codelite-make, never heard of that... Let's search:

ERROR: unsatisfiable constraints:
  codelite (missing):
    required by: world[codelite]

Nope, the repositories don't know what codelite is either as nothing exits with codelite in the name... Is it something you have to download manually? To the Google! Apparently it has to be downloaded from https://github.com/eranif/codelite/archive/13.0.tar.gz so grabbing it, untar'ing it, and Oh Hey codelite is a CMake project! Well this should be easy (oy it uses wxWidgets, haven't seen that in years, and it uses the old gtk2, so old it's not even on my old ubuntu dev system that contains just about every common library on it, interesting...):

/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c: In function 'readChars':
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:609:13: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'        
  if(location.__pos < 0)                                                                                                                           
             ^                                                                                                                                     
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:623:21: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'        
  sizeToRead = endPos.__pos - location.__pos;                                                                                                      
                     ^                                                                                                                             
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:623:38: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'        
  sizeToRead = endPos.__pos - location.__pos;                                                                                                      
                                      ^

Huh, their code is bad... How do they manage to compile this?? Bah, grabbing an old repo with it and installing it that way (hate mixing repo versions...), and done.

Trying the PyBuild.py script again, the make commands seem to work now, however getting a lot of errors of:

[ERROR ] Could not load build settings configuration object (Version 2.1 / build_settings.xml)
make: *** No targets specified and no makefile found.  Stop.

A whole lot of those. Let's find them:

╰─➤  find . -name build_settings.xml

Uh, so... they don't exist... The last part of the PyBuild.py output was again:

Failed Builds list:
('VisibilityBuffer.workspace/VisibilityBuffer', 'Debug', 'Ubuntu')
('VisibilityBuffer.workspace/VisibilityBuffer', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/01_Transformation', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/02_Compute', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/03_MultiThread', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/04_ExecuteIndirect', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/05_FontRendering', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/07_Tessellation', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/08_Procedural', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/06_MaterialPlayground', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/09_LightShadowPlayground', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/09a_HybridRaytracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/10_PixelProjectedReflections', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/13_UserInterface', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/14_WaveIntrinsics', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/15_Transparency', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/16_Raytracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/16a_SphereTracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/17_EntityComponentSystem', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/18_Playback', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/19_Blending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/20_JointAttachment', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/21_PartialBlending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/22_AdditiveBlending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/23_BakedPhysics', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/24_MultiThread', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/25_Skinning', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/01_Transformation', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/02_Compute', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/03_MultiThread', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/04_ExecuteIndirect', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/05_FontRendering', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/07_Tessellation', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/08_Procedural', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/06_MaterialPlayground', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/09_LightShadowPlayground', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/09a_HybridRaytracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/10_PixelProjectedReflections', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/13_UserInterface', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/14_WaveIntrinsics', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/15_Transparency', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/16_Raytracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/16a_SphereTracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/17_EntityComponentSystem', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/18_Playback', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/19_Blending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/20_JointAttachment', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/21_PartialBlending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/22_AdditiveBlending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/23_BakedPhysics', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/24_MultiThread', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/25_Skinning', 'Release', 'Ubuntu')

The command '/bin/sh -c python2 ./PyBuild.py' returned a non-zero code: 255

Still no clue how to load this project into KDevelop (it uses cmake as it's default but also supports make, ninja, and a few others, though it has no clue what to make of this git repo) or into emacs or vim (basically the same support).

So yes, from a linux perspective there is no clue how to use this project. It has no standard build system that is understood by any tool that I've ever seen (and by far cmake is the standard build tool for C++ anymore, whether on linux, mac, windows, etc...).

I have a windows 10 system here as well but I got even less far than on linux, the dependency management here on windows is beyond horrible and this project doesn't use any multiplatform C++ dependency management system like Hunter.sh (or the less portable ones like even conan or vcpkg)....

Really badly need docs on how to build. ^.^

Optimally, building would be as something as simple as:

git clone https://github.com/ConfettiFX/The-Forge.git && cd The-Forge && cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Release -DWHATEVER_BUILD_ARGS_FOR_THE_FORGE_HERE=Blah -DTHE_FORGE_BUILD_EXAMPLES=True && cmake --build build --config Release

Or if using KDevelop or emacs or vi or Visual Studio or IntelliC++ or any other number of a few dozen popular C++ IDE's then I should be able to just git clone https://github.com/ConfettiFX/The-Forge.git then load the The-Forge/CMakeLists.txt file as the project and everything Just Works, this is generally what is expected nowadays (and yes that even works fine in modern Windows Visual Studio's too as I have to use for some work projects). Or they should be able to use this project as a git submodule in their own project and just add_subdirectory("deps/The-Forge") or so and it would 'just work' as a library dependency. No need to make sure that sqlite development libraries are installed systemwide (though can use them instead of acquiring the dependency if they exist of course, though I like repeatable builds so proper dependency management is always preferred) or vulkan development libraries (though want the runtime libraries installed system-wide via GPU drivers to actually be able to 'run' the examples) or whatever else.

But so far I've gotten to this point, which I've wrapped up in a simple Dockerfile:

FROM ubuntu:18.04

WORKDIR "/The-Forge"

RUN apt update && apt upgrade -y && apt install -y \
        gcc \
        g++ \
        git \
        build-essential \
        cmake \
        bash \
        curl \
        cppcheck \
        python2.7 \
        codelite \
        libsqlite3-dev \
        libwxbase3.0-dev

RUN rm -rf /var/cache/apt/*

RUN git clone https://github.com/ConfettiFX/The-Forge.git /The-Forge

RUN bash ./PRE_BUILD.command

RUN python2 ./PyBuild.py

ENTRYPOINT [ "bash", "-c" ]

[OvermindDL1]

As an addendum, wasn't able to figure out how to cross-compile to windows from linux either. With cmake that's as trivial as supplying a cross-build toolchain file (which cmake comes with, though I usually use more capable toolchain files for my own setups) to the cmake build command (which also works with any IDE supported by cmake or that cmake supports, and yes cmake supports codelite just fine so cmake should be used with codelite), but I can't seem to find any method at all to do it with the PyBuild.py file after some perusing of it..

[OvermindDL1]

what would be a good reason to use cmake? It adds another step to the build process that can fail and it is not supported by most of our target platforms.

So back to this now that I've gone through trying to build it. CMake would be a standard set of commands that would work with everything. CMake would be a lot faster considering cache support and ninja backend support and so forth (all built in, you don't need to do anything). CMake would support cross-platform without doing anything (unless breaking it purposefully by doing something like compiling local called tools in-process instead of using the local toolchain instead of the passed in toolchain, but that's easy to fix if broken). CMake would actually work in IDE's (including codelite, apparently this project is broken with codelite 13, which is the only one available in the local repository here). CMake would entirely remove that entire PyBuild.py file with something thats standard and understandable by people that traditionally use C and C++. CMake has a huge set of extensions and plugins like drop-in UnityFile building for significantly faster and more optimized Release builds in exchange for using more memory for the build (user controlled of course). CMake would give actual proper log files of every command that is run and everything that is performed and all. Etc... etc... etc...

And yes, it not only supports all of the targeted systems, they are all First-Class supported targets (I.E. fully built in to CMake without the user needing to supply a custom toolchain file).

Thus overall it significantly increases compatibility, reduces the failure area, removes a lot of exceptionally disjoint things like the PyBuild.py and a lot of very weird XML files and platform specific useless files, increases maintainability, actually proper logging support, etc... etc...

sorry i found it PRE_BUILD.command. i'm not familiar with command files so didn't recognize.

Likewise, I had no clue what a *.command file was other than I've seen it on windows related to powershell contexts before, so I wasn't touching it on linux until I saw it listed in the README.md, that is an extremely non-standard extension! ^.^;

The file actually being marked as executable in git would have made it immediately obvious that it could be run on linux though. :-)

[OvermindDL1]

As an aside, I'm curious how codelite compares to the other IDE's I use for C++ (KDevelop, CLion, and emacs), so I took a quick look. :-)

First of all, the website's gallery doesn't work in chrome or firefox on linux nor windows 10, no errors in the JS console and no JS blocked, so unsure what's up with that, didn't look further in to it. Not a great sign though as this is the first thing people looking at it will see... Thankfully middle click works.

Grabbed codelite13 from the main repository, trivial enough to grab, single command.

Ah, it has cmake support built in to it too, even less reason for it's workspace files to exist then!

Opened a fairly complex project in it with dependency management and all purely in a cmake project, everything was built and acquired properly.

Its intellisense is rather lacking (though compared to KDevelop and CLion most intellisense's are rather lacking), seems to be basic type-aware autocomplete (probably via libclang it wouldn't surprise me, it seems to handle constructs well enough for that), nothing else. It has some basic templates like generating getters/setters (its casing does not follow modern standards, very weird...), but nothing really larger or type aware. Can't find a way to perform step-by-step MACRO or template expansions like with KDevelop or CLion. It's not suggesting to use modern C++ constructs like the override specifier and so forth.

The debugging seems to be a basic GDB wrapper, very basic it seems, simple breakpoint and memory watching, not seeing any immediately obvious way to submit gdb commands for anything more powerful. Both KDevelop (linux/mac/windows) and CLion's (linux/mac/windows) (and emacs (windows/mac/linux/phones/toasters/etc...) of course) have significantly more powerful debugging interfaces.

Wow, it has a wxForm builder, really haven't seen one of these in years. Seems decent if you only need to use the build-in controls but seems to have no support for project-specific controls short of just an empty frame for them, so it seems to be pretty lacking (though I usually just did my forms in code 15+ years ago in wxWidgets instead of using any builder, the builders don't really gain anything over that).

It has a really basic DB interface, lacking a ton of features that would actually be useful for DB work so wouldn't see it being used over other tools.

It has a simple git differ, but seems to have no git timeline support that I can really find so it can only do really basic diff's, wouldn't be used over other tools.

It 'feels' quite a bit old, I don't mean in coding quality or so as it is fast enough, but rather in features and interface. KDevelop is all around better as an IDE, and CLion is probably even better than that (though it's a touch bit laggy at times because it's made in kotlin/java). It's even lacking pretty basic features from my emacs C++ setup.

It's an interesting IDE, but really basic and doesn't bring anything useful to the table compared to the usual IDE's used. I'm really confused as to why it's workspace files are scattered around this repository.

[boberfly]

Hi @OvermindDL1 & @pgruenbacher If it helps, try out my small fork here which uses CMake: https://github.com/boberfly/The-Forge-Lite

However it just comes with 01_Transformations as a unit test. To add more unit tests, I have made a macro in the CMake file which lets you easily add the others (with a bit of formatting of the headers, and commenting out the UI stuff until I add that in).

Cheers

[OvermindDL1]

@boberfly Great start there! It compiles clean and fast! :-)

[Hideman85]

Hello I tried also to build on Linux and I'm also annoying to don't see any CMakeLists.txt that is now the base on c++ projects and really easy to use build tool chain in order to cross-compile for different systems. I tried to compile using PyBuild.py but got error No target found... I tried also the repo cite just above it compile fine (just one sample) but at execution it failed and just have segfault with no logs. I finally successful build into the main repo by running codelite and open the workspace xml file but got also directly a segfault when running.

So finally I'm so confuse for testing this project.

[OvermindDL1]

@Hideman85, what's the full callstack of the segfault, are you sure vulkan works on your system, what's the output of vulkaninfo?

[Hideman85]

Yes my system work perfectly with Vulkan and I already test Acid and DiligentEngine that work with vulkan too. I have no stacktrace for the segfault but I found a log file https://pastebin.com/2Vnq9aXN And vulkaninfo dump all characteristic of my both graphic cards:

Groups :
========
    Device Group Properties (Group 0) :
        physicalDeviceCount = 1
            AMD RADV HAINAN (LLVM 7.0.0) (ID: 0)
        subsetAllocation = 0

    Device Group Properties (Group 1) :
        physicalDeviceCount = 1
            Intel(R) Haswell Mobile (ID: 0)
        subsetAllocation = 0

And it select the dedicated card so it's perfect.

[OvermindDL1]

You should be able to get the stacktrace by either turning on coredumps and opening that with gdb, or just loading the program with gdb and waiting for it to crash then dumping the stacktrace, make sure you build with debug symbols. :-)

[Hideman85]

Sorry but this IDE is definitely not for me. I'm also not able to import this project with CLion. I'm completely lost, where in codelite I'm able to look for the current build profile, compilation flags etc. Because even running in «Debug mode» I got nothing :(

Idem with gdb stacktrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6b7c1094d0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
[Current thread is 1 (Thread 0x7f6b7d0d4080 (LWP 3660))]
#0  0x00007f6b7c1094d0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
#1  0x00007f6b7c0b1e0f in ?? ()
   from /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
#2  0x00005616a119ad00 in ?? ()
#3  0x0000000000000001 in ?? ()
#4  0x00007ffeccee5c30 in ?? ()
#5  0x00007ffeccee5e00 in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x00005616a11991a0 in ?? ()

No way even clean project and run «Build and debug»

[OvermindDL1]

Sorry but this IDE is definitely not for me.

Not clue, I couldn't really use that IDE either, it seems to be lacking quite a lot, so I used the-forge-lite via cmake for my tests. ^.^;

Program terminated with signal SIGSEGV, Segmentation fault.

0 0x00007f6b7c1094d0 in ?? ()

from /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so

This on the other hand sounds like either bad data send 'to' vulkan or a bad driver, maybe try updating your kernel and/or MESA?

[Hideman85]

But it's really bizzard I can run DiligentEngine for example (with cmake ;) )

[boberfly]

@Hideman85 looks like you are running the mesa radv driver, I have a PR fix for that segfault here: https://github.com/ConfettiFX/The-Forge/pull/118

Cheers

[Hideman85]

Yes it works fine with your fix thanks ;)