Closed Thom1729 closed 4 years ago
This is weird - and it doesn't seem to be an issue with OpenSWE1R (as you can safely ignore the warnings).
It appears to be an issue with how your CMake / GLEW are configured. CMake seems to find GLEW, but probably doesn't set the right variables / paths, so the linker fails.
I followed the build instructions, installing from brew:
brew install cmake
brew install sdl2 unicorn glew openal-soft enet
Here's my complete brew list --versions
:
cabextract 1.9.1
cmake 3.15.1
coreutils 8.30
enet 1.3.14
gdbm 1.18.1
glew 2.1.0
icu4c 63.1
ncurses 6.1
node 11.10.0
openal-soft 1.19.1
openssl 1.0.2q
p7zip 16.02_1
python 3.7.2
readline 7.0.5
sdl2 2.0.9_1
sqlite 3.26.0
unicorn 1.0.1
unrar 5.7.5
wine 4.0.1
winetricks 20190615
xz 5.2.4
zsh 5.6.2_1
I've verified that the cmake I ran is the brew version. I also tried running the brew version of gmake, with the same result.
I've looked into it.
Starting in CMake 3.15, the GLEW handling was updated. It now prefers the cmake config that ships with GLEW.
I consider this problematic, because the GLEW config is not compatible with old CMake versions / configurations; it only has the import target.
Note how the standard / legacy CMake variables are gone.
The solution will be to change OpenSWE1R to import targets, away from legacy result variables.
Last time I intended to do this, I had reports that this wasn't in all distributions yet because of older CMake versions. Support for GLEW::GLEW was added in 2014 - however, we already target CMake 3.1 anyway, and the import targets remained stable.
I couldn't successfully build the project on Mac OS 10.13.6. Please let me know if any other information would help.