VirtualGL / virtualgl

Main VirtualGL repository
https://VirtualGL.org
Other
701 stars 106 forks source link

CMake cannot find libturbojpeg #188

Closed jamie-arcc closed 2 years ago

jamie-arcc commented 2 years ago

I am trying to compile VirtualGL 3.0 on CentOS 7.8 using cmake 3.20.0 with a locally built libjpeg-turbo version 2.1.2 but cmake cannot find the library, even with TJPEG_LIBRARY set to the correct path of the static library as directed by the cmake output. The CMakeError output shows that cmake is not using this variable, but is instead trying to link with -lturbojpeg in the test. build/CMakeFiles/CMakeError.log is attached. CMakeError.log

dcommander commented 2 years ago

The good news is that you aren't crazy, but the bad news is that CMake apparently is. 😐 If TJPEG_LIBRARY is unspecified, then the VGL build system first tries to find the TurboJPEG API library under /opt/libjpeg-turbo (the install location for the official libjpeg-turbo SDK packages.) If it fails to find the library there, then it tries to link with a system-supplied version of the TurboJPEG API library (-lturbojpeg.) If both tests fail, then the build system throws a fatal error. If you run CMake again, specifying a new value for TJPEG_LIBRARY, then I would expect that CMake would re-run the TURBOJPEG_WORKS test, but it doesn't seem to. Instead it seems to cache the results of the failing tests from the first run and re-print those results to CMakeError.log. I think that the following patch should work around the issue. Can you confirm?

--- a/cmakescripts/FindTurboJPEG.cmake
+++ b/cmakescripts/FindTurboJPEG.cmake
@@ -46,6 +46,12 @@ set(CMAKE_REQUIRED_DEFINITIONS)
 set(CMAKE_REQUIRED_INCLUDES)
 set(CMAKE_REQUIRED_LIBRARIES)
 if(NOT TURBOJPEG_WORKS AND NOT SYSTEM_TURBOJPEG_WORKS)
+  unset(TJPEG_LIBRARY)
+  unset(TJPEG_LIBRARY CACHE)
+  unset(TURBOJPEG_WORKS)
+  unset(TURBOJPEG_WORKS CACHE)
+  unset(SYSTEM_TURBOJPEG_WORKS)
+  unset(SYSTEM_TURBOJPEG_WORKS CACHE)
   message(FATAL_ERROR "Could not link with TurboJPEG library ${TJPEG_LIBRARY}.  If it is installed in a different place, then set TJPEG_LIBRARY accordingly.")
 endif()
jamie-arcc commented 2 years ago

I don't know if I'm doing something wrong, but patch failed.

[jschnaitter@emgnt1 virtualgl-3.0]$ patch -p1 < FindTurboJPEG.patch
patching file cmakescripts/FindTurboJPEG.cmake
Hunk #1 FAILED at 46.
1 out of 1 hunk FAILED -- saving rejects to file cmakescripts/FindTurboJPEG.cmake.rej
dcommander commented 2 years ago

Be sure you're copying the blank line at the end of it. That line should have a single space and nothing else.

jamie-arcc commented 2 years ago

I originally was indeed missing that final line, but even with that fixed I am still getting the same error. Attached is the patch file (changed extension to .txt so github wouldn't whine)

FindTurboJPEG.txt

jamie-arcc commented 2 years ago

I went ahead and manually added those lines to the script. It seems to have fixed it (I am now hitting errors about a bunch of the X11_ and OpenCL_ vars being set to NOTFOUND when I generate), however we probably shouldn't be unsetting TJPEG_LIBRARY, as I think that is causing ccmake to no longer prompt for that variable. I am also wondering if it would make sense to have the cmake scripts for virtualgl use either the pkgconfig or cmake scripts that are included with libjpeg-turbo to find it

dcommander commented 2 years ago

Good call on not unsetting TJPEG_LIBRARY. As far as the package config scripts, unfortunately it's kind of a chicken-and-egg problem. The official libjpeg-turbo packages include those scripts under /opt/libjpeg-turbo, so we'd still have to look for them both there and in the system default location. Also, some supported Linux distros are still using older versions of libjpeg-turbo that don't include the scripts. (pkg-config support was added in libjpeg-turbo 1.5.x, and CMake package config support was added in libjpeg-turbo 2.1.x.)

jamie-arcc commented 2 years ago

Ah, that makes sense.

Thanks for responding so quickly and for your help!

dcommander commented 2 years ago

No problem! Sorry for the confusion with the patch. Now I know that I can attach it with a .txt extension next time.

jamie-arcc commented 2 years ago

It's silly that GitHub is picky about file extensions when we in the Unix world know that they don't mean anything