glm: gource and logstalgia can't not find glm header

[barracuda156]

--->  Configuring logstalgia
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_logstalgia/logstalgia/work/logstalgia-1.1.4" && ./configure --prefix=/opt/local --with-boost=/opt/local/libexec/boost/1.76 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... powerpc-apple-darwin10.0.0d2
checking host system type... powerpc-apple-darwin10.0.0d2
checking for a sed that does not truncate output... /opt/local/bin/gsed
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/g++-4.2 accepts -g... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of /usr/bin/g++-4.2... gcc3
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gcc... /usr/bin/gcc-4.2
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/gcc-4.2 accepts -g... yes
checking for /usr/bin/gcc-4.2 option to accept ISO C89... none needed
checking whether /usr/bin/gcc-4.2 understands -c and -o together... yes
checking dependency style of /usr/bin/gcc-4.2... gcc3
checking how to run the C++ preprocessor... /usr/bin/g++-4.2 -E
checking for grep that handles long lines and -e... /opt/local/bin/ggrep
checking for egrep... /opt/local/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking how to run the C preprocessor... /usr/bin/gcc-4.2 -E
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking for compiling a minimal OpenGL program... yes
checking for linking a minimal OpenGL program... yes
checking for OpenGL/glu.h... yes
checking for compiling a minimal OpenGL Utility (GLU) program... yes
checking for linking a minimal GLU program... yes
checking if GLU varargs tesselator is using non-standard form... no
checking for FT2... yes
checking for PCRE2... yes
checking for GLEW... yes
checking for SDL2... yes
checking for PNG... yes
checking for IMG_LoadPNG_RW... yes
checking for IMG_LoadJPG_RW... yes
checking for boostlib >= 1.46 (104600) includes in "/opt/local/libexec/boost/1.76/include"... yes
checking for boostlib >= 1.46 (104600) lib path in "/opt/local/libexec/boost/1.76/lib/powerpc-darwin10.0.0d2"... no
checking for boostlib >= 1.46 (104600) lib path in "/opt/local/libexec/boost/1.76/lib"... yes
checking for boostlib >= 1.46 (104600)... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system-mt... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem-mt... yes
checking glm/glm.hpp usability... no
checking glm/glm.hpp presence... no
checking for glm/glm.hpp... no
configure: error: GLM headers are required. Please see INSTALL
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_logstalgia/logstalgia/work/logstalgia-1.1.4" && ./configure --prefix=/opt/local --with-boost=/opt/local/libexec/boost/1.76 
Exit code: 1

[ryandesign (Ryan Carsten Schmidt)]

I don't see this problem on macOS 12. Can you attach the config.log?

[ryandesign (Ryan Carsten Schmidt)]

I see you are on Snow Leopard building for PowerPC. We didn't see this problem on Snow Leopard building for Intel, nor on Mavericks or later, but we did see this error on Lion and Mountain Lion. I updated glm to 1.0.1 and retried the 10.7 and 10.8 logstalgia builds and they still failed.

[barracuda156]

Replying to ryandesign:

I see you are on Snow Leopard building for PowerPC. We didn't see this problem on Snow Leopard building for Intel, nor on Mavericks or later, but we did see this error on Lion and Mountain Lion. I updated glm to 1.0.1 and retried the 10.7 and 10.8 logstalgia builds and they still failed.

This is a really strange selection of OS/archs.

Having an updated glm is good anyway, even if this issue is unresolved.

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

This is a really strange selection of OS/archs to fail.

Not necessarily. The versions of clang on 10.7 and 10.8 are "old". On 10.6, Xcode clang is so old that we don't try to use it anymore; we use a "new" MacPorts clang instead when building for Intel. Your build on 10.6 was for PowerPC for which clang doesn't work so it used gcc-4.2, another "old" compiler.

gource (the only other port that has a build dependency on glm) fails with the same error message on 10.8 but not on 10.7. gource requires C++11, so it needs Apple clang 500 or later. The 10.8 buildbot worker has this; the 10.7 worker doesn't so a "new" MacPorts clang would be used there. logstalgia doesn't specify a C++ requirement so it used "old" Apple clang on both 10.7 and 10.8. This suggests the problem is that the glm headers require something that's only available in Apple clang 600 or later. The config.log should have more specifics.

Maybe it is something that can be fixed in the glm headers, or maybe everything using the glm headers needs Apple clang 600 or later. Hopefully it's the former, because the glm port says it only requires C++98. The glm build system has flags one can use to indicate which C++ standard should be used, and we don't use any of those flags in the glm port which means it auto-detects. You could try rebuilding the glm port from source after adding the flag that forces it to use C++98.

(I am away from an Intel machine and probably won't have time to try it there soon.)

Since the problem seems to relate to "old" compilers, testing on PowerPC may work, if that's more convenient.