Compilation fails with glm 0.9.9.3

Bug #1804030 reported by Victor W on 2018-11-19
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KiCad
High
Seth Hillbrand

Bug Description

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

Tags: glm Edit Tag help
Nick Østergaard (nickoe) wrote :

This is a known issue

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

So a quick fix is to downgrade glm.

tags: added: glm
description: updated
Seth Hillbrand (sethh) wrote :

So many issues with GLM changing the API every version.

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

Changed in kicad:
milestone: none → 5.1.0
importance: Undecided → High
status: New → Triaged
Wayne Stambaugh (stambaughw) wrote :

@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) wrote :

@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) wrote :

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

Changed in kicad:
status: Triaged → Fix Committed
assignee: nobody → Seth Hillbrand (sethh)
Maciej Suminski (orsonmmz) 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?

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) wrote :

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) wrote :

@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.

Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.