AcademySoftwareFoundation / aswf-docker

Common container configuration
Apache License 2.0
145 stars 35 forks source link

GLEW CMake config error in 2020 images #43

Open michdolan opened 4 years ago

michdolan commented 4 years ago

While moving OCIO CI to GH Actions I encountered a linking error with the GLEW install in the aswf/ci-base:2020 images. When configuring a build with CMake within this container, GLEW is found through the default FindGLEW.cmake module with the following output:

-- Found GLEW: /usr/local/lib64/cmake/glew/glew-config.cmake

In the aswf/ci-base:2019 the same configure step finds GLEW at:

-- Found GLEW: /usr/local/include

The 2019 result links properly, but the 2020 result results in the following linking error during the OCIO build:

[ 73%] Linking CXX executable ociodisplay
../../libutils/oglbuilder/libOpenColorIOoglbuilder.a(glsl.cpp.o): In function `OpenColorIO_v2_0dev::OpenGLBuilder::Uniform::setUp(unsigned int)':
glsl.cpp:(.text+0x122): undefined reference to `__glewGetUniformLocation'
...
CMakeFiles/ociodisplay.dir/main.cpp.o: In function `main':
main.cpp:(.text.startup+0x65): undefined reference to `glewInit'
main.cpp:(.text.startup+0x6f): undefined reference to `glewIsSupported'
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/apps/ociodisplay/ociodisplay] Error 1

I worked around the failure by deleting the GLEW CMake config before running cmake with:

sudo rm -rf /usr/local/lib64/cmake/glew

Following that, the find module behaves identically to the 2019 container.

aloysbaillet commented 4 years ago

Would you be able to check if this problem still exists with the new 2020 images I've released today? They have changed quite a bit...

michdolan commented 4 years ago

It exists in aswf/ocio-ci:2020 (which is the same digest as 2020.3 correct?). I used the above mentioned workaround to resolve it.

jfpanisset commented 3 years ago

I can confirm that this also an issue with the aswf/ci-ocio:2021 Docker image. With the following test CMakeLists.txt:

project(foo)
find_package(GLEW)
message(STATUS "GLEW_LIBRARIES is ${GLEW_LIBRARIES}")
message(STATUS "GLEW_INCLUDE_DIRS is ${GLEW_INCLUDE_DIRS}")
message(STATUS "GLEW_FOUND is ${GLEW_FOUND}")

you get:

-- Found GLEW: /usr/local/lib64/cmake/glew/glew-config.cmake
-- GLEW_LIBRARIES is
-- GLEW_INCLUDE_DIRS is
-- GLEW_FOUND is TRUE

but if you remove /usr/local/lib64/cmake/glew/glew-config.cmake from the container, instead:

-- Found GLEW: /usr/local/include (found version "2.1.0")
-- GLEW_LIBRARIES is /usr/local/lib64/libGLEW.so
-- GLEW_INCLUDE_DIRS is /usr/local/include
-- GLEW_FOUND is TRUE

which allows the OpenGL apps and test suite to link correctly (not finding GLEW_INCLUDE_DIRS is not a problem since -I/usr/local/include presumably comes from somewhere else, but not finding the GLEW libraries causes linking errors).

It looks like this is the last thing needed to get OpenGL builds/runs using the Amazon CodeBuild infrastructure, so it would be great to figure this out.

hodoulp commented 3 years ago

Here is the code of glew-config.cmake which does not create the 'usual' variables. It only defines GLEW::GLEW.

Here is the cmake issue 19662 (fixed) related to GLEW to enhance the variables to have the missing GLEW_LIBRARIES and GLEW_INCLUDE_DIRS.

aloysbaillet commented 3 years ago

Thanks @hodoulp ! Do you think we should apply this patch in the docker images? I'm OK either way.

hodoulp commented 3 years ago

@aloysbaillet The change is now in OCIO but if other projects need GLEW I think it's worth centralizing the change in the docker scripts.