cmake fails on Gentoo-based systems that have a program installed called `apt`

[stamasd]

The current revision of the code fails to configure with cmake on non-Debian systems. Cmake looks for /etc/debian_version and if that file doesn't exist, it fails. That file does not exist on systems that are not based on Debian.

Trying to build on Funtoo (Gentoo-based distribution) results in:

-- Configuring Packaging for Linux -- Configuring Debian Packaging CMake Error at CMakeLists.txt:1316 (FILE): FILE failed to open for reading (No such file or directory):

/etc/debian_version

Looking for /home/silviu/vegastrike/Vega-Strike-Engine-Source/engine/build1/dependency.list Still need to generate dependency list SEND_WARNING!! Unsupported Debian version. -- Configuring incomplete, errors occurred! See also "/home/silviu/vegastrike/Vega-Strike-Engine-Source/engine/build1/CMakeFiles/CMakeOutput.log". See also "/home/silviu/vegastrike/Vega-Strike-Engine-Source/engine/build1/CMakeFiles/CMakeError.log".

This wasn't happening the last time I built it, about a month ago.

[stephengtuggy]

Hmm. That's very odd.

We have CI (Continuous Integration) builds running on a variety of Linux distributions -- both Debian-based and RPM-based -- for each change that is made to master. If CMake truly fails on all non-Debian-based systems, we should have caught that.

Can you try running script/clean from your Vega Strike root directory, and then try running CMake again? Also, I'm assuming that you are using the latest code from the master branch?

[stamasd]

Hm, on second look that may not be the problem. I have just tested it on another system, also Funtoo, and it configures and builds fine. Also notice that the above is not an error but a warning. The same warning is issued on configuring on the second system, but there configuration doesn't fail.

Unfortunately I won't have access to the initial system until late tonight (it's my home desktop, and the second one is my work laptop; I'm at work now) to investigate further. Something may be missing there, but I don't think I saw any actual errors thrown into the output of cmake. I did not however check the error log, my fault.

To answer the other questions, yes the code was a fresh git pull as of last evening. Funtoo is neither Debian nor RPM-based, but portage-based. I have been building VS on it for years and this is the first time I had a problem.

Will update here once I take a look again tonight when I'm home.

[stamasd]

Well, I don't know what's wrong and why it won't build. The same code, on 2 different systems running the same distribution, one builds the other doesn't. And I don't see any difference in the CMakeError.log between the two.

I'll be attaching the CMakeError.log files for the 2 systems.

First the one where configuring fails. CMakeError.log

Then the one from the system where configuring and building is successful. CMakeError.log

here's also the console output of cmake on the system where it fails:

~/vegastrike/Vega-Strike-Engine-Source/build2 $ cmake ../engine/ ++ Disabling Position Independent Executables/Shared Libraries (Recommended on Ubuntu/Mint) ++ Python release(s) searched for : 3.9;3.8;3.7;3.6;3.5;3.4 ++ Python library : /usr/lib/libpython3.7m.so (3.7.10) ++ Python include dir : /usr/include/python3.7m ++ Using System Boost -- Found Boost: /usr/include (found version "1.72.0")
++ Found System Boost version : 1.72.0 -- Boost_1_67_Or_Later_Result: TRUE ++ Looking for System Boost::python -- Found Boost: /usr/include (found version "1.72.0") found components: python37 log log_setup date_time system filesystem thread chrono atomic regex ++ Found System Boost::python ++ OpenGL found : /usr/lib/libOpenGL.so;/usr/lib/libGLX.so;/usr/lib/libGLU.so ++ GLUT found : /usr/lib/libglut.so;/usr/lib/libXmu.so;/usr/lib/libXi.so ++ Found OpenAL ++ SDL Found -- Found Vorbis: /usr/lib/libvorbis.so;/usr/lib/libvorbisfile.so;/usr/lib/libogg.so -- FFMPEG disabled -- Ogre disabled CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:426 (message): The package name passed to find_package_handle_standard_args (GTK3_GTK) does not match the name of the calling package (GTK3). This can lead to problems in calling code that expects find_package result variables (e.g., _FOUND) to follow a certain pattern. Call Stack (most recent call first): FindGTK3.cmake:546 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) setup/CMakeLists.txt:18 (FIND_PACKAGE) This warning is for project developers. Use -Wno-dev to suppress it.

-- Compiling vega-meshtool without OgreMesh support: Ogre not found -- Default build type is RelWithDebInfo, no cpu opts enabled. ++ Building with BUILD_OPT: -O2 ++ Building with CMAKE_CXX_FLAGS: Linking with : vegastrike-engine_com;vegastrike-OPcollide;/usr/lib/libpython3.7m.so;/usr/lib/libboost_python37-mt.so;/usr/lib/libboost_log-mt.so;/usr/lib/libboost_log_setup-mt.so;/usr/lib/libboost_date_time-mt.so;/usr/lib/libboost_system-mt.so;/usr/lib/libboost_filesystem-mt.so;/usr/lib/libboost_thread-mt.so;-lpthread;/usr/lib/libboost_chrono-mt.so;/usr/lib/libboost_atomic-mt.so;/usr/lib/libboost_regex-mt.so;/usr/lib/libOpenGL.so;/usr/lib/libGLX.so;/usr/lib/libGLU.so;/usr/lib/libglut.so;/usr/lib/libXmu.so;/usr/lib/libXi.so;/usr/lib/libopenal.so;/usr/lib/libSDLmain.a;/usr/lib/libSDL.so;-lpthread;/usr/lib/libvorbis.so;/usr/lib/libvorbisfile.so;/usr/lib/libogg.so;/usr/lib/libjpeg.so;/usr/lib/libpng.so;/usr/lib/libz.so;/usr/lib/libz.so;/usr/lib/libexpat.so;/usr/lib/libm.so;/usr/lib/libutil.so including : /home/silviu/vegastrike/Vega-Strike-Engine-Source/engine/src;/home/silviu/vegastrike/Vega-Strike-Engine-Source/engine/src/cmd;/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2;/usr/include/harfbuzz;/usr/include/python3.7m;/usr/include;/usr/include/python3.7m;/usr/include;/usr/include;/usr/include/AL;/usr/include/SDL;/usr/include/vorbis;/usr/include/ogg;/usr/include;/usr/include;/usr/include;/usr/include Newer CMake version, using preferred method -- Configuring Packaging for Linux -- Configuring Debian Packaging CMake Error at CMakeLists.txt:1316 (FILE): FILE failed to open for reading (No such file or directory):

/etc/debian_version

Looking for /home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/dependency.list Still need to generate dependency list SEND_WARNING!! Unsupported Debian version. -- Configuring incomplete, errors occurred! See also "/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeOutput.log". See also "/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeError.log".

[stephengtuggy]

Very strange.

Does one of your systems happen to have a program called apt or apt-get installed, where the other one doesn't? That's the only way I can see that this would happen.

[BenjamenMeyer]

@stamasd are you sure you uploaded the right files? I'm showing the same error in both of them:

  /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpthreads
  collect2: error: ld returned 1 exit status                                                  
  gmake[1]: *** [CMakeFiles/cmTC_3af16.dir/build.make:106: cmTC_3af16] Error 1
  gmake[1]: Leaving directory '/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeTmp'
  gmake: *** [Makefile:140: cmTC_3af16/fast] Error 2

  Determining if the function pow exists failed with the following output:                    
  Change Dir: /home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeTmp

  Run Build Command(s):/usr/bin/gmake cmTC_dfb0f/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_dfb0f.dir/build.make CMakeFiles/cmTC_dfb0f.dir/build
  gmake[1]: Entering directory '/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeTmp'
  Building C object CMakeFiles/cmTC_dfb0f.dir/CheckFunctionExists.c.o
  /usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pow -o CMakeFiles/cmTC_dfb0f.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
  <command-line>: warning: conflicting types for built-in function ‘pow’; expected ‘double(double,  double)’ [-Wbuiltin-declaration-mismatch]
  /usr/share/cmake/Modules/CheckFunctionExists.c:7:3: note: in expansion of macro ‘CHECK_FUNCTION_EXISTS’
      7 |   CHECK_FUNCTION_EXISTS(void);                                                      
        |   ^~~~~~~~~~~~~~~~~~~~~                                                             
  /usr/share/cmake/Modules/CheckFunctionExists.c:1:1: note: ‘pow’ is declared in header ‘<math.h>’
    +++ |+#include <math.h>                                                                   
      1 | #ifdef CHECK_FUNCTION_EXISTS                                                        
  Linking C executable cmTC_dfb0f
  /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_dfb0f.dir/link.txt --verbose=1
  /usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pow CMakeFiles/cmTC_dfb0f.dir/CheckFunctionExists.c.o -o cmTC_dfb0f 
  /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/cmTC_dfb0f.dir/CheckFunctionExists.c.o: in function `main':
  CheckFunctionExists.c:(.text+0x10): undefined reference to `pow'                            
  collect2: error: ld returned 1 exit status                                                  
  gmake[1]: *** [CMakeFiles/cmTC_dfb0f.dir/build.make:106: cmTC_dfb0f] Error 1
  gmake[1]: Leaving directory '/home/silviu/vegastrike/Vega-Strike-Engine-Source/build2/CMakeFiles/CMakeTmp'
  gmake: *** [Makefile:140: cmTC_dfb0f/fast] Error 2

I'm guessing you don't have all the dependencies installed.

WRT /etc/debian_version, which Debian distro are you running? Or did you install apt on a non-Debian distro?

[stamasd]

Very strange.

Does one of your systems happen to have a program called apt or apt-get installed, where the other one doesn't? That's the only way I can see that this would happen.

No. There is no apt or apt-get on either of them. There is no reason for either to exist as they are not Debian-based.

[stamasd]

@stamasd are you sure you uploaded the right files? I'm showing the same error in both of them:

WRT /etc/debian_version, which Debian distro are you running? Or did you install apt on a non-Debian distro?

That is precisely what puzzles me. The same errors, but on one system configure succeeds, on the other it doesn't. I do have all dependencies, I checked one by one that I have the Funtoo equivalent of all of them. Funtoo is not based on Debian but on Gentoo. There is no apt on either system. It uses portage and the functional equivalent of apt is 'emerge'

[BenjamenMeyer]

@stamasd I'm aware of Funtoo; I'm curious why it detected apt though. It shouldn't be looking for /etc/debian_version unless it detects that apt or apt-get is installed.

My question about the files is that both files show failure, specifically the inability to link to the pow function:

CheckFunctionExists.c:(.text+0x10): undefined reference to `pow'  

so if one really succeeded, then it wasn't included in your uploads.

[stamasd]

I think I solved the mystery. On the machine where compilation fails, I do have an /usr/bin/apt. HOWEVER, it is NOT the Debian tool called 'apt'. It's a file belonging to the Java bindings of a Gentoo-specific tool, 'eselect'. Specifically, the package app-eselect/eselect-java. I have uninstalled that package, and with the fake apt gone now vegastrike configures and builds correctly (even though cmake still spits out the same error log).

As a take-home lesson from the above, when using cmake for configuring vegastrike on a Gentoo or derivative system, it should verify that /usr/bin/apt is actually the Debian tool, and not something else.

Why eselect-java uses a file called /usr/bin/apt, that I don't know.

[stamasd]

FWIW, running the "fake" apt by itself gives the following output:

~/vegastrike/Vega-Strike-Engine-Source/build2 $ apt

• apt is not available for oracle-jdk-bin-1.8 on x86_64
• IMPORTANT: some Java tools are not available on some VMs on some architectures

[stephengtuggy]

Aha! So there was a different program that happened to be called apt, installed on the system that had the issue. That would explain it.

Currently, the only thing CMake looks at to determine if a Linux system is Debian-based or not is the existence of an apt or apt-get program. That may need to change.

[stephengtuggy]

@stamasd I took the liberty of renaming the issue ticket. Let me know what you think.

[stamasd]

that seems appropriate Also in that particular situation, there is a binary called apt but there is no apt-get

[BenjamenMeyer]

@stamasd interesting... FWIW, our APT check is for either apt-get or apt...it might be better to check for some of the dpkg tools (like dpkg-buildpackage) instead of apt/apt-get.

[stamasd]

either that, or check for Gentoo-specific tools like emerge - and if it is found, it should override the check for apt

[BenjamenMeyer]

@stamasd I wouldn't check for emerge unless we were adding Gentoo support.

That said, it would be great to add a Gentoo Ebuild and Portage Overlay support. The Ebuild is basically instructions for doing the build so emerge can just do it. If we have the ebuild we could figure out a proper hosting strategy. A Ebuild could send in settings for CMake to be able to make it all work correctly for Gentoo/Emerge.

[stamasd]

Yeah I know what an ebuild is... but I've never made one. :)

Let me see what I can do. I'll probably find someone to help me.

[stamasd]

In the meantime, I have made a little patch for Gentoo/Funtoo that will allow cmake to work correctly even if there is that /usr/bin/apt installed. cp CMakeLists.gentoo.patch vegastrikelocation/Vega-Strike-Engine-Source/engine cd vegastrikelocation/Vega-Strike-Engine-Source/engine && patch CMakeLists.txt <Cmakelists.gentoo.patch

After that, cmake configures the engine properly on Gentoo/Funtoo. It's a dirty hack but it works.

and since github doesn't allow .patch extensions, I'll add a .txt at the end of the patch file CMakeLists.gentoo.patch.txt

[stamasd]

Or the same done with sed:

sed -i 's/FIND_PROGRAM(HAS_APT NAMES apt-get apt)/FIND_PROGRAM(HAS_APT NAMES _thereisnoapt)/g' CMakeLists.txt

[BenjamenMeyer]

@evertvorster This should be fixed by #553. I'll port it to 0.8.x after it gets merged to master.

[BenjamenMeyer]

Still need to port to 0.8.x

[stephengtuggy]

Still need to port to 0.8.x

@BenjamenMeyer Yes, you are correct. The issue was linked to the PR, such that when the PR was merged, it closed the issue automatically. But we do still need it open for 0.8.x implementation.