Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Andrew Caudwell]

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 <acaudwell at gmail.com>
wrote:

> Hi,
>
> On Sat, Mar 17, 2018 at 9:31 AM, Guus Sliepen <guus at 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 <guus at debian.org>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20180328/c6eacaf9/attachment.html>