[Fixed] CMake configure failure

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

CMake configure failure

Postby parkerlreed » Sun Jan 31, 2021 3:53 am

Been compiling GZDoom with Vulkan on my Switch running Linux (Arch Linux ARM)

Worked fine for the longest time but now I'm running into something weird on the CMake configure step. Any idea what could be going on?

Code: Select allExpand view
$     cmake -B build \
          -D CMAKE_BUILD_TYPE=Release \
          -D CMAKE_CXX_FLAGS="${CXXFLAGS} -ffile-prefix-map=\"$PWD\"=. -DSHARE_DIR=\\\"/usr/share/gzdoom\\\"" \
          -D DYN_GTK=OFF \
          -D DYN_OPENAL=OFF \
          -D HAVE_VULKAN=ON
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found BZip2: /usr/lib/libbz2.so (found version "1.0.8")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Found JPEG: /usr/lib/libjpeg.so (found version "80")
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11")
-- Looking for fts_set
-- Looking for fts_set - found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE 
-- Using system zlib, includes found at /usr/include
-- Using system jpeg library, includes found at /usr/include
-- Using system bzip2 library, includes found at /usr/include
CMake Deprecation Warning at libraries/lzma/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at tools/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at tools/re2c/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Looking for strdup
-- Looking for strdup - found
-- Looking for strndup
-- Looking for strndup - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of 0i8
-- Check size of 0i8 - failed
-- Check size of 0l
-- Check size of 0l - done
-- Check size of 0ll
-- Check size of 0ll - done
-- Check size of char
-- Check size of char - done
-- Check size of short
-- Check size of short - done
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of long long
-- Check size of long long - done
-- Check size of void *
-- Check size of void * - done
-- Check size of __int64
-- Check size of __int64 - failed
CMake Deprecation Warning at tools/lemon/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at tools/zipdir/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at libraries/gdtoa/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at wadsrc/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at wadsrc_bm/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at wadsrc_lights/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at wadsrc_extra/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at wadsrc_widescreen/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3")
-- Found ZMusic: /usr/lib/libzmusic.so 
Building for target architecture: arm64
-- Checking for module 'gtk+-3.0'
--   Found gtk+-3.0, version 3.24.24
-- Found SDL2: /usr/lib/libSDL2main.a;/usr/lib/libSDL2.so;-pthread 
-- Found OpenAL: /usr/lib/libopenal.so 
-- Performing Test HAVE_MMX
-- Performing Test HAVE_MMX - Failed
-- Performing Test HAVE_PARALLEL_FOR
-- Performing Test HAVE_PARALLEL_FOR - Failed
-- Performing Test HAVE_DISPATCH_APPLY
-- Performing Test HAVE_DISPATCH_APPLY - Failed
-- Performing Test HAVE_THREAD_LOCAL
-- Performing Test HAVE_THREAD_LOCAL - Failed
CMake Error at src/CMakeLists.txt:373 (message):
  C++ compiler doesn't support thread_local storage duration specifier


-- Looking for filelength
-- Looking for filelength - not found
-- Looking for strupr
-- Looking for strupr - not found
-- Looking for stricmp
-- Looking for stricmp - not found
-- Looking for strnicmp
-- Looking for strnicmp - not found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
-- Could NOT find OpenMP (missing: OpenMP_CXX_FOUND) (found version "4.5")
-- Looking for backtrace
-- Looking for backtrace - found
-- backtrace facility detected in default set of libraries
-- Found Backtrace: /usr/include 
-- Configuring incomplete, errors occurred!
See also "/home/parker/build/gzdoom-git/src/gzdoom/build/CMakeFiles/CMakeOutput.log".
See also "/home/parker/build/gzdoom-git/src/gzdoom/build/CMakeFiles/CMakeError.log".


EDIT: Attempted with disabling OpenMP as I realized that's an x86 thing but it still errors out.

Code: Select allExpand view
-D NO_OPENMP=ON


The thread_local seems like a likely cause but the current note says it *should* be optional

Code: Select allExpand view
# Check for thread_local keyword, it's optional at the moment

CHECK_CXX_SOURCE_COMPILES("thread_local int i; int main() { i = 0; }"
        HAVE_THREAD_LOCAL)

if( NOT HAVE_THREAD_LOCAL )
        message( SEND_ERROR "C++ compiler doesn't support thread_local storage duration specifier" )
endif()
parkerlreed
 
Joined: 31 Jan 2021
Operating System: Other Linux ARM/PPC/etc
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby _mental_ » Sun Jan 31, 2021 4:07 am

Like it was suggested at the end of CMake output, post CMakeOutput.log and CMakeError.log files.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: CMake configure failure

Postby parkerlreed » Sun Jan 31, 2021 4:13 am

parkerlreed
 
Joined: 31 Jan 2021
Operating System: Other Linux ARM/PPC/etc
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby parkerlreed » Sun Jan 31, 2021 4:23 am

Found that reverting this commit lets it build https://github.com/coelckers/gzdoom/com ... 9e7dc85ccf

What's strange is I have definitely built this successfully on this same platform well past 2018.
parkerlreed
 
Joined: 31 Jan 2021
Operating System: Other Linux ARM/PPC/etc
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby _mental_ » Sun Jan 31, 2021 4:36 am

Can you do CMake configuration to a new build directory without reverting anything and with -DUSE_LINUX_ARM=OFF argument added?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: CMake configure failure

Postby parkerlreed » Sun Jan 31, 2021 4:46 am

Yep that configures "correctly". I assume there's some new ARM handling?

thread_local is apparently not a thing for ARM and I ran into one other ARM related line

https://github.com/coelckers/gzdoom/blo ... s.txt#L329

NEON and Hard Float were optional in the AMRV7 days but became part of the base spec in ARMV8. At least on my current compiler (GCC 10.2.0) both NEON and Hard Float don't exist as options (I guess the Pi does something special for their compiler to keep them enabled?). Maybe a Pi specific branch of that if else could work. Not sure how that would be implemented :/
parkerlreed
 
Joined: 31 Jan 2021
Operating System: Other Linux ARM/PPC/etc
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby Rachael » Sun Jan 31, 2021 5:09 am

Hmmm I had to do this yesterday for my Raspberry Pi, as well, in order to get it to build. Not by turning off -DUSE_LINUX_ARM, but by turning off that error.

However, trying out now by turning off DUSE_LINUX_ARM - yeah it's time for that to go. Since ARM64 is the only officially supported platform at this point (I am no longer supporting ARM32) I might as well remove it completely.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby parkerlreed » Sun Jan 31, 2021 5:15 am

Aha! Good to know. Yeah as far as I am aware, if you build anything on ARMV8 NEON and Hard Float are implied and don't have to be specified (and in fact can't be specified)

Update on the generic USE_LINUX_ARM=OFF build: compiled and runs great. I am seeing one weird oddity where running gzdoom by itself initializes Vulkan but then instantly falls back to OpenGL. If I run it with mangohud (to get an FPS overlay) Vulkan is used and works as expected. Seems without a Vulkan Layer enabled (of which mangohud is one), it's failing to use it. This may be down to my setup though so more testing is needed on my end.
parkerlreed
 
Joined: 31 Jan 2021
Operating System: Other Linux ARM/PPC/etc
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby Rachael » Sun Jan 31, 2021 5:18 am

fixed

I did not realize that ARM64 didn't need those lines at all - and removing them makes the compile go smoothly.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby Graf Zahl » Sun Jan 31, 2021 5:40 am

You somehow managed to nuke the commits from the last two weeks by doing a force push. Unfortunately I do not have everything that got lost - _mental_'s latest changes are missing on my system so can someone please repair the repo?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: CMake configure failure

Postby Rachael » Sun Jan 31, 2021 5:44 am

Grrr. Git is being a ... git again.

That had some work that was not supposed to be there, but I did not mean to erase two week's worth of stuff either. I pulled it out of my reflog and re-merged it.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby drfrag » Sun Jan 31, 2021 5:55 am

May be you pushed from the wrong branch? But nothing has been lost as i see it, now there are three extra merges and a revert. May be it's time for a hard reset to "replaced linked sector constructor with default initializers"? What i did was to merge that commit in my master.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: CMake configure failure

Postby Rachael » Sun Jan 31, 2021 5:57 am

No, what happened was a commit was made to master that was not supposed to be made to master. I don't know how it got in my master branch, and that's why I reverted it. Then I figured since the ink was still wet I probably could just erase those two completely, but somehow ended up nuking 2 weeks of work as Graf said - so - whatever, fuck it, it's there.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: CMake configure failure

Postby Graf Zahl » Sun Jan 31, 2021 6:16 am

What git tool were you using?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: CMake configure failure

Postby drfrag » Sun Jan 31, 2021 6:24 am

I know there's a serious bug in Tortoisegit and it's that when you add a new remote your push default changes to the first remote (upstream) instead of origin. That's a problem when you have write permission in that repo.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests