schnaader/precomp-cpp

Compiling development branch using GCC

M-Gonzalo opened this issue · 11 comments

I'm refering to deus-libri/preflate#1 (comment)

The inclusion of the preflate library breaks the compiling process using the 'make' command.

I'll have a look at the CMake file and try compiling under Linux/MacOS. Most likely the other variants (Makefile and make.bat) will vanish in this process, so only the CMake file will be left.

@M-Gonzalo : You should now be able to build under Linux using CMake, could you verify this? I had a successful build with a Docker image of Ubuntu 16.04.3.

Thanks for having a look at it.
Apparently, the compiling process works, but I'm not able to finish it due to an error:

EDIT: Better see the whole log in the next message

I have the latest Ubuntu 18.04 with gcc 7.3

Here is a complete log of the Nth try, using the latest cmake (downloaded from the official site instead of the repository), and gcc 8. Please pay especial attention to line 18. That's the first red flag, and I can't get rid of it. I read somewhere on the web that cmake had a bug impeding it to recognize pthread_create but it's the same with the new version.

precomp_preflate_compile.log

The uint16_t errors look very familiar to me, but I have only encountered them when the compiler was too old and did not support C++11. Maybe some include is missing? Try adding #include <cstdint> to preflate_seq_chain.h and other source files, and make sure the compiler is set to use C++11 or 14

The uint16_t errors look very familiar to me, but I have only encountered them when the compiler was too old and did not support C++11. Maybe some include is missing? Try adding #include <cstdint> to preflate_seq_chain.h and other source files, and make sure the compiler is set to use C++11 or 14

Will try. Thanks for the tip.

Finally, adding
#include <cstdint>
to these two files:

./contrib/preflate/preflate_predictor_state.h
./contrib/preflate/preflate_seq_chain.h

...did the trick. I didn't test it on Windows though. I don't know if it breaks something but at least on linux compiles just fine.


First tests report no crashes. OTOH, it's very much slower than the Windows counterpart.
For example:
38 seconds windows run using wine
54 seconds linux run
That's 16 s of difference. Almost a 50% slower

I used a temp folder in ram (/dev/shm) to avoid disk thrashing.

<cstdint> is a standard C/C++ library header file, including it really should not break anything, except if the compiler does not support it.
So this may break really old versions of MSVC++, that do not support C++11. But that should not be an issue, since people on windows can just use TDM-GCC or some other MinGW64 based toolchain to get a sufficiently recent version of GCC.

Thanks @M-Gonzalo and @Diazonium for further investigation, fixed this and verified that the Windows build still works.

@M-Gonzalo : If you run cmake from the command line, call it like this:
"cmake -DCMAKE_BUILD_TYPE=Release path_to_cmake_lists/"
It will create a debug build by default, which will be much larger (for me: 2,4 MB for debug, 1,2 MB for release) and slower.

@M-Gonzalo : If you run cmake from the command line, call it like this:
"cmake -DCMAKE_BUILD_TYPE=Release path_to_cmake_lists/"
It will create a debug build by default, which will be much larger (for me: 2,4 MB for debug, 1,2 MB for release) and slower.

duh!! Didn't think of that. Now it is indeed a lot faster (about 2.5x)
Thanks!