Upstream has implemented my suggestion to re-add default initialization as opt-in via a new define:
https://github.com/g-truc/glm/issues/735 https://github.com/g-truc/glm/commit/8390a77b3a278b15259e5ca6e67f7e41badc457b Could you apply the commit as a patch so maintainers can then define GLM_FORCE_CTOR_INIT and avoid having to modifying code? Let me know as then I can then avoid having to embed the current release in my software. Thanks On Fri, Mar 23, 2018 at 3:07 PM, Andrew Caudwell <acaudw...@gmail.com> wrote: > Hi, > > On Sat, Mar 17, 2018 at 9:31 AM, Guus Sliepen <g...@debian.org> wrote: > >> tags 892861 + wontfix >> thanks >> >> On Wed, Mar 14, 2018 at 10:48:33AM +1300, Andrew Caudwell wrote: >> >> > The packaged version of GLM, 0.9.9~a2 is an alpha (the current release >> is still >> > 0.9.8.5) and removes the default initialization of vector, matrix and >> > quaternion types. Because of this code written against any earlier >> versions of >> > GLM may now have uninitialized value bugs introduced by this change >> (e.g. where >> > GLM types are member variables of a class) or now behave differently >> (mat4() >> > previously gave you an identity matrix, now this gives you a zero'd >> matrix). >> > Several issues have been raised upstream (including by myself) to re-add >> > initialization or at least make it optional. >> > Additionally the requirement in this version to define >> GLM_ENABLE_EXPERIMENTAL >> [...] >> > to use simple functions like length2() has broken multiple packages. I >> have put >> > off fixing this since making it compile just exposes the user to the >> > uninitialized value bugs. Unfortunately this has now meant my gource and >> > logstalgia debian packages have been removed from debian since they >> don't >> > complile with this GLM version. >> >> I believe these are intentional changes by the author of GLM. I expect >> that GLM 1.0.0 will be released before the next release of Debian, and >> any packages that depend on GLM should instead be fixed to handle the >> new behavior. >> > > The upstream author hasn't commented on these issues yet so there's no > reason to assume they will leave things in the current state without at > least providing at least a work around to the initialization issue. > >> >> Unless I am mistaken, projects depending on GLM can just #define >> GLM_ENABLE_EXPERIMENTAL and provide explicit default initializers, which >> will be backwards compatible with older versions of GLM. >> > > Fixing the default initializers issue requires a thorough code review and > probably debugging with valgrind to find these cases (-Wuninitialized won't > find these) which I think is an unreasonable burden on maintainers. > > Other distros such as Redhat, Gentoo and Arch Linux have continued to > package the current release 0.9.8.5 with a fix for the GCC 7.3 issue (which > only requires changing an == to >=): > > https://git.archlinux.org/svntogit/community.git/tree/ > trunk/PKGBUILD?h=packages/glm > > Ubuntu 18.04 has imported the current Debian unstable libglm-dev package > which has made resolving this issue more urgent in my view. > > My current work around is to embed the patched version of 0.9.8.5 and > provide a --with-glm option for distros that have a compatible version of > the library. > > Ideally I would like to be able to use the Debian libglm-dev package so I > hope you reconsider. > > Cheers > > Andrew > > > >> >> -- >> Met vriendelijke groet / with kind regards, >> Guus Sliepen <g...@debian.org> >> > >
-- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
