This should fix#2260186 by updating to the latest upstream version
There is again an installation mechanism, so that the patch adding
that could be removed. On the other hand, new patch removing the
-Werror compiler option had to be introduced.
New upstream release (#1823615)
The previous workaround for getting installation support was no longer
applicable. New installation support is under review at [1] and this
was backported to 0.9.9.8, with hope that the PR will land in master
before the next upstream release.
The version configuration file generated by cmake by default has a
slight problem. It checks that the pointer width of the detected library
matches the project being built. This check would usually have little
significance to a header-only library, but it breaks with our noarch
packages which may well get built on a 32-bit host and then get deployed
e.g. on x86_64.
This fixes bug #1758009
New upstream release
Support for running "make install" had disappeared between versions
0.9.9.5 and 0.9.9.6. Upstream seems to be working on adding it back,
but for now, it seems that we can patch the support back in for this
version.
These failing items should be reported upstream as well, but here
they are just marked so that the package can be built. This is not
expected to cause any more problems to library consumers than the
exact same code provided by upstream.
Unfortunately there is now known actual fix for these failing
tests. The library is still mostly useful so let's keep testing that
there is no fedora-specific breakage.
Changes similar to those in
glm-0.9.6.1-bigendian.patch and glm-0.9.6.3-nom64.patch
had appeared in upstream sources, so these patches were
dropped.
GLM has started shipping cmake config files, so these
are now provided by glm-devel.
The patch for fixing aliasing issues is not required or applicable
anymore, due to GLM having fixed the issues.
The float distance counting algorithm entered an infinite loop in
some cases. The glm-0.9.6.1-ulp.patch addresses this.