Fabián Orccón

I confirm that the problem is caused by building it in release mode with ``` set(CMAKE_BUILD_TYPE Release) ``` I at least need the Release mode to use it with dlib,...

A guy from the ##c++ IRC channel suggest to compile with -DCMAKE_C_FLAGS="-Wall -Wextra" and fix all the warnings, since there may be an undefined behavior.

I will double check. But this is not the problem in the index order. I just compile the same code from the examples with "set(CMAKE_BUILD_TYPE Release)" and I get this...

The problem is because I am compiling with ``` set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_BUILD_TYPE Release) ``` So the combination of using -std=c++14 and Release mode is what leads to this...

The reason why I compile with C++14 standard is because otherwise I get this error when I compile the code with eos+dlib: [https://gist.github.com/cfoch/64b116cc1a2449051051ff14a9702daf](https://gist.github.com/cfoch/64b116cc1a2449051051ff14a9702daf)

Sorry for the delay... ``` [cfoch@localhost bin]$ uname -rio 4.18.16-300.fc29.x86_64 x86_64 GNU/Linux ``` ``` [cfoch@localhost bin]$ cat /etc/redhat-release Fedora release 29 (Twenty Nine) ``` gcc/g++ version ``` [cfoch@localhost bin]$ g++...

Thank you. I solved it basically after checking the command line output using VERBOSE=1 as you suggested. ``` set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_BUILD_TYPE Release) ``` made the trick! :100:

It is enough to me having this "just working". However, it does not work when building it on the C++14 standard. But since the description of this project states "A...

Same here.

@ldaneliukas any workaround for your mentioned case? The only idea for now is defining an output on job1, and checking for that output on job `if` condition.