Compilation fails with glm 0.9.9.3

[Victor W]

When trying to compile the kicad git from source, it fails. This seems to be due to the incremental update of glm 0.9.9.3 on archlinux.

When downgrading glm to 0.9.9.2, kicad git compiles without error.

The following errors and warnings occur when trying to compile using Archlinux, glm 0.9.9.3 are:

===
-- KiCad install dir: </usr>
-- Check for installed GLEW -- found
-- Found GLM: /usr/include (found suitable version "0.9.9.3", minimum required is "0.9.5.1")
-- Boost version: 1.68.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/site-packages
-- S3DSG version: 2.0.0
-- Boost version: 1.68.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Boost version: 1.68.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Boost version: 1.68.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/src/pacman/kicad-git/src/kicad-git/build
===
[ 30%] Built target version_header
[ 30%] Built target legacy_wx
[ 30%] Built target pcb_plot_lexer_source_files
[ 30%] Built target page_layout_lexer_source_files
[ 30%] Built target legacy_gal
[ 32%] Built target gal
[ 32%] Built target lib_table_lexer_source_files
[ 32%] Built target netlist_lexer_source_files
[ 43%] Built target common
[ 44%] Built target pcb_lexer_source_files
[ 44%] Building CXX object common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o
In file included from /usr/include/glm/ext/vector_bool2.hpp:5,
                 from /usr/include/glm/vec2.hpp:5,
                 from /usr/include/glm/glm.hpp:116,
                 from /usr/src//-git/src/kicad-git/include/plugins/3dapi/xv3d_types.h:38,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/../3d_canvas/../3d_rendering/3d_render_raytracing/accelerators/../shapes2D/../ray.h:33,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/../3d_canvas/../3d_rendering/3d_render_raytracing/accelerators/../shapes2D/cbbox2d.h:33,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/../3d_canvas/../3d_rendering/3d_render_raytracing/accelerators/../shapes2D/cobject2d.h:33,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/../3d_canvas/../3d_rendering/3d_render_raytracing/accelerators/ccontainer2d.h:33,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/../3d_canvas/cinfo3d_visu.h:34,
                 from /usr/src//-git/src/kicad-git/common/../3d-viewer/3d_viewer/eda_3d_viewer.h:35,
                 from /usr/src//-git/src/kicad-git/pcbnew/pcb_base_frame.cpp:42:
/usr/include/glm/detail/type_vec2.hpp:90:40: error: ‘constexpr const T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const’ cannot be overloaded with ‘constexpr T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const’
   GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;
                                        ^~~~~~~~
/usr/include/glm/detail/type_vec2.hpp:89:34: note: previous declaration ‘constexpr T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const’
   GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);
                                  ^~~~~~~~

<snip>

4.18.16-arch1-1-ARCH

[Nick Østergaard (nickoe)]

This is a known issue

See https://lists.launchpad.net/kicad-developers/msg38290.html

So a quick fix is to downgrade glm.

[Nick Østergaard (nickoe)]

https://github.com/g-truc/glm/issues/832

[Seth Hillbrand (sethh)]

So many issues with GLM changing the API every version.

We should probably fork/keep a specific version as our GLM usage is light.

[Wayne Stambaugh (stambaughw)]

@Seth, I'm not sure we can fix this. I appears to actually be an issue with glm 0.9.9.3. There is a fix provided in the links provided by Nick. Can we close this as invalid?

[Seth Hillbrand (sethh)]

@Wayne- We could keep GLM 0.9.7.6 in our repository. The library is header-only, so there's no difference for our compile scripts and doesn't impact distros other than ones that are compile-based. I pick 0.9.7.6 as it is the last one that doesn't have a performance regression on 32-bit (https://github.com/g-truc/glm/issues/803)

[KiCad Janitor (kicad-janitor)]

Fixed in revision 968ea983aa4ce0cdf837344c4344c0d5380a78ac
https://git.launchpad.net/kicad/patch/?id=968ea983aa4ce0cdf837344c4344c0d5380a78ac

[Maciej Suminski (orsonmmz)]

Seth,

Given the problems new GLM versions create, it sounds reasonable to me to keep the GLM library in KiCad repository. Wayne, do you have anything against?

[Wayne Stambaugh (stambaughw)]

Hey Orson,

On 12/16/2018 12:36 PM, Maciej Suminski wrote:
> Seth,
>
> Given the problems new GLM versions create, it sounds reasonable to me
> to keep the GLM library in KiCad repository. Wayne, do you have anything
> against?
>

I'm torn. I've not a big fan of embedding dependency project code in
KiCad because will will have to constantly sync the code when bug fixes
and improvement are made but I understand the frustration caused by
broken KiCad builds due to changes in these dependencies. Since this
seems to be a gcc vs clang issue, maybe a better solution would be to
clamp the version when building against gcc and allow version 0.9.9.3 to
be used when clang is used. I suspect that the next version of glm will
have the fix for gcc so this may be a short lived issue. AFAIK, it's
the first time we have encountered build issues with glm. I'm not
opposed to embedding glm but I also don't want to be burdened with the
maintenance issues either.

Cheers,

Wayne

[Seth Hillbrand (sethh)]

Hi Wayne-

I was thinking of lp:1746546

Both of these issues were due to unnecessary changes in the GLM codebase. Clang seems to work because it is not as strict with the C++14 limits as gcc. Once we move to --std=c++14, gcc will work with this version of glm again.

Maybe we hold off and see if these issues continue. n=2 is not a great sample size, I suppose.

[Wayne Stambaugh (stambaughw)]

@Seth, let's see what surprises the next revision of glm brings. If there continues to be issues, then I fine with falling back to including the library in the kicad source.