Marcus Müller <mmueller@gnuradio.org> writes:
> would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?
I commented in the PR, but it applies to 3.3.0, builds under pkgsrc with
gcc 10, and passes tests. Looks good to merge from my viewpoint.
Wednesday, February 11, 2026
Monday, February 9, 2026
Re: [VOLK] Release 3.3.0
Hello Greg,
would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?
Hello Johannes,
sadly I could not find a way that both introduces no random new includes in volk_common.h
that causes functional changes in consumers of the header, while still addressing the
issue Greg describes; the cleanest seems to be moving the mostly-internal math functions
out of volk_common.h to a new header.
That of course means API breakage; sorry.
Best regards,
Marcus
On 2026-02-09 5:39 PM, Marcus Müller wrote:
> hm that volk_common.h is generally not that well-structured; I'd advocate for having
> something like `volk_cos_poly` in a different file than basic type and attribute
> declarations that get used all over the place. I'll make a PR to that end; if you could
> test that, Greg, it'd be much appreciated.
>
> Best regards,
> Marcus
>
> On 2026-02-08 8:57 PM, Greg Troxel wrote:
>> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>>
>>> Hey Greg,
>>>
>>> thanks for picking up the release so quickly. I haven't seen this issue
>>> with any of the CI compilers.
>>> Would there be a way to reproduce that in a docker container?
>>
>> You could add NetBSD 10 the CI farm. (I am not clear on how docker
>> works.)
>>
>>
>> It seems this is pretty hard:
>>
>> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
>> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
>> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-
>> you-might-think
>> (section "absolute mess")
>>
>> another possibility is to use __builtin_isnan, which works
>> on gcc and clang but that's not portable to other compilers that comply
>> with standards.
>>
>> From reading lots of things, I have taken away that in C++ code isnan
>> should always be written std::isnan(), have not found anything
>> indicating that writing it that way is at all bad, and that it's
>> unspecified if abs without std:: works or not.
>>
>>
>>
>
would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?
Hello Johannes,
sadly I could not find a way that both introduces no random new includes in volk_common.h
that causes functional changes in consumers of the header, while still addressing the
issue Greg describes; the cleanest seems to be moving the mostly-internal math functions
out of volk_common.h to a new header.
That of course means API breakage; sorry.
Best regards,
Marcus
On 2026-02-09 5:39 PM, Marcus Müller wrote:
> hm that volk_common.h is generally not that well-structured; I'd advocate for having
> something like `volk_cos_poly` in a different file than basic type and attribute
> declarations that get used all over the place. I'll make a PR to that end; if you could
> test that, Greg, it'd be much appreciated.
>
> Best regards,
> Marcus
>
> On 2026-02-08 8:57 PM, Greg Troxel wrote:
>> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>>
>>> Hey Greg,
>>>
>>> thanks for picking up the release so quickly. I haven't seen this issue
>>> with any of the CI compilers.
>>> Would there be a way to reproduce that in a docker container?
>>
>> You could add NetBSD 10 the CI farm. (I am not clear on how docker
>> works.)
>>
>>
>> It seems this is pretty hard:
>>
>> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
>> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
>> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-
>> you-might-think
>> (section "absolute mess")
>>
>> another possibility is to use __builtin_isnan, which works
>> on gcc and clang but that's not portable to other compilers that comply
>> with standards.
>>
>> From reading lots of things, I have taken away that in C++ code isnan
>> should always be written std::isnan(), have not found anything
>> indicating that writing it that way is at all bad, and that it's
>> unspecified if abs without std:: works or not.
>>
>>
>>
>
Re: [VOLK] Release 3.3.0
Marcus Müller <mmueller@gnuradio.org> writes:
> place. I'll make a PR to that end; if you could test that, Greg, it'd
> be much appreciated.
Sure, please feel free to @gdt (github and codeberg) or email me a link
and I'll try it.
Johannes: I realize that having bougght into github CI that it's not a
great portability situation as the set of available runners is very
limited. I am struggling with this myself on an unrelated project, but
so far more inclined to put energy into leaving github and some
beyond-github future CI more than improving CI on github, even if it's
not so much either way :-(
Someone else updated volk to 3.3.0 and here's the patch they arrived at.
I'm not a fan of doing it this way (upstream), but it does more or less
show the issue well.
--- include/volk/volk_common.h.orig 2026-02-09 12:27:43.544508041 +0000
+++ include/volk/volk_common.h
@@ -150,7 +150,12 @@ union bit256 {
////////////////////////////////////////////////////////////////////////
// log2f
////////////////////////////////////////////////////////////////////////
+#ifdef __cplusplus
+#include <cmath>
+using std::isinf, std::isnan;
+#else
#include <math.h>
+
> place. I'll make a PR to that end; if you could test that, Greg, it'd
> be much appreciated.
Sure, please feel free to @gdt (github and codeberg) or email me a link
and I'll try it.
Johannes: I realize that having bougght into github CI that it's not a
great portability situation as the set of available runners is very
limited. I am struggling with this myself on an unrelated project, but
so far more inclined to put energy into leaving github and some
beyond-github future CI more than improving CI on github, even if it's
not so much either way :-(
Someone else updated volk to 3.3.0 and here's the patch they arrived at.
I'm not a fan of doing it this way (upstream), but it does more or less
show the issue well.
--- include/volk/volk_common.h.orig 2026-02-09 12:27:43.544508041 +0000
+++ include/volk/volk_common.h
@@ -150,7 +150,12 @@ union bit256 {
////////////////////////////////////////////////////////////////////////
// log2f
////////////////////////////////////////////////////////////////////////
+#ifdef __cplusplus
+#include <cmath>
+using std::isinf, std::isnan;
+#else
#include <math.h>
+
Re: [VOLK] Release 3.3.0
Hey Greg,
Our CI consists of the GitHub runners that are available through this channel. If there's a service to add netbsd runners, please let me know. That'd be a great addition.
Besides, Marcus suggestion to fix things sounds good either way.
Cheers
Johannes
On Mon, 9 Feb 2026, 17:39 Marcus Müller, <mmueller@gnuradio.org> wrote:
hm that volk_common.h is generally not that well-structured; I'd advocate for having
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.
Best regards,
Marcus
On 2026-02-08 8:57 PM, Greg Troxel wrote:
> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>
>> Hey Greg,
>>
>> thanks for picking up the release so quickly. I haven't seen this issue
>> with any of the CI compilers.
>> Would there be a way to reproduce that in a docker container?
>
> You could add NetBSD 10 the CI farm. (I am not clear on how docker
> works.)
>
>
> It seems this is pretty hard:
>
> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
> (section "absolute mess")
>
> another possibility is to use __builtin_isnan, which works
> on gcc and clang but that's not portable to other compilers that comply
> with standards.
>
> From reading lots of things, I have taken away that in C++ code isnan
> should always be written std::isnan(), have not found anything
> indicating that writing it that way is at all bad, and that it's
> unspecified if abs without std:: works or not.
>
>
>
Re: [VOLK] Release 3.3.0
hm that volk_common.h is generally not that well-structured; I'd advocate for having
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.
Best regards,
Marcus
On 2026-02-08 8:57 PM, Greg Troxel wrote:
> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>
>> Hey Greg,
>>
>> thanks for picking up the release so quickly. I haven't seen this issue
>> with any of the CI compilers.
>> Would there be a way to reproduce that in a docker container?
>
> You could add NetBSD 10 the CI farm. (I am not clear on how docker
> works.)
>
>
> It seems this is pretty hard:
>
> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
> (section "absolute mess")
>
> another possibility is to use __builtin_isnan, which works
> on gcc and clang but that's not portable to other compilers that comply
> with standards.
>
> From reading lots of things, I have taken away that in C++ code isnan
> should always be written std::isnan(), have not found anything
> indicating that writing it that way is at all bad, and that it's
> unspecified if abs without std:: works or not.
>
>
>
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.
Best regards,
Marcus
On 2026-02-08 8:57 PM, Greg Troxel wrote:
> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>
>> Hey Greg,
>>
>> thanks for picking up the release so quickly. I haven't seen this issue
>> with any of the CI compilers.
>> Would there be a way to reproduce that in a docker container?
>
> You could add NetBSD 10 the CI farm. (I am not clear on how docker
> works.)
>
>
> It seems this is pretty hard:
>
> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
> (section "absolute mess")
>
> another possibility is to use __builtin_isnan, which works
> on gcc and clang but that's not portable to other compilers that comply
> with standards.
>
> From reading lots of things, I have taken away that in C++ code isnan
> should always be written std::isnan(), have not found anything
> indicating that writing it that way is at all bad, and that it's
> unspecified if abs without std:: works or not.
>
>
>
Sunday, February 8, 2026
Re: [VOLK] Release 3.3.0
Johannes Sterz Demel <jdemel@gnuradio.org> writes:
> Hey Greg,
>
> thanks for picking up the release so quickly. I haven't seen this issue
> with any of the CI compilers.
> Would there be a way to reproduce that in a docker container?
You could add NetBSD 10 the CI farm. (I am not clear on how docker
works.)
It seems this is pretty hard:
https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
(section "absolute mess")
another possibility is to use __builtin_isnan, which works
on gcc and clang but that's not portable to other compilers that comply
with standards.
From reading lots of things, I have taken away that in C++ code isnan
should always be written std::isnan(), have not found anything
indicating that writing it that way is at all bad, and that it's
unspecified if abs without std:: works or not.
> Hey Greg,
>
> thanks for picking up the release so quickly. I haven't seen this issue
> with any of the CI compilers.
> Would there be a way to reproduce that in a docker container?
You could add NetBSD 10 the CI farm. (I am not clear on how docker
works.)
It seems this is pretty hard:
https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
(section "absolute mess")
another possibility is to use __builtin_isnan, which works
on gcc and clang but that's not portable to other compilers that comply
with standards.
From reading lots of things, I have taken away that in C++ code isnan
should always be written std::isnan(), have not found anything
indicating that writing it that way is at all bad, and that it's
unspecified if abs without std:: works or not.
Re: [VOLK] Release 3.3.0
Hey Greg,
thanks for picking up the release so quickly. I haven't seen this issue with any of the CI compilers.
Would there be a way to reproduce that in a docker container?
Cheers
Johannes
On Sun, 8 Feb 2026, 18:32 Greg Troxel, <gdt@lexort.com> wrote:
Johannes Demel <jdemel@gnuradio.org> writes:
> I just tagged the VOLK v3.3.0 release! We want to thank all
> contributors. This release wouldn't have been possible without them.
Thanks - I am trying to update the pkgsrc entry, and running into a
problem that's awkward to patch.
In include/volk/volk_common.h, there is frequent usage of
isnan
isinf
If the heaader is included by a C program, this is fine.
If it is included by a C++ program, then it appears to mean std::isnan,
but it is not specified if C++ compilers have to allow bare isnan to
refer to std::isnan or not. gcc 10 on NetBSD does not allow this, and
many other projects have fixed isnan to std::isnan (in a C++ context).
The difficulty here is that the header, while marked c++ for emacs mode,
is trying to be both C and C++.
Perhaps the fix is to #if on cpluslus and define our_isnan to
std::isnan and if not to isnan, but I hope somebod who understands C++
better than I do knows a nicer way.
=> Bootstrap dependency digest>=20211023: found digest-20220214
===> Checking for vulnerabilities in volk-3.3.0
===> Building for volk-3.3.0
[1/10] Building CXX object lib/CMakeFiles/volk_test_all.dir/testqa.cc.o
FAILED: [code=1] lib/CMakeFiles/volk_test_all.dir/testqa.cc.o
/tmp/work/math/volk/work/.cwrapper/bin/c++ -DFMT_SHARED -DHAVE_CPUID_H -DHAVE_DLFCN_H -DHAVE_FENV_H -D_GLIBCXX_USE_CXX11_ABI=1 -I/tmp/work/math/volk/work/.buildlink/include/orc-0.4 -I/tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include -I/tmp/work/math/volk/work/volk-3.3.0/include -I/tmp/work/math/volk/work/volk-3.3.0/kernels -isystem /tmp/work/math/volk/work/.buildlink/include -O2 -I/usr/include -I/usr/pkg/include/python3.13 -I/usr/pkg/include -Wall -fvisibility=hidden -DNDEBUG -std=c++17 -MD -MT lib/CMakeFiles/volk_test_all.dir/testqa.cc.o -MF lib/CMakeFiles/volk_test_all.dir/testqa.cc.o.d -o lib/CMakeFiles/volk_test_all.dir/testqa.cc.o -c /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h: In function 'float log2f_non_ieee(float)':
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:161:9: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
161 | if (isnan(result))
| ^~~~~
| std::isnan
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:632:5: note: 'std::isnan' declared here
632 | isnan(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:164:12: error: 'isinf' was not declared in this scope; did you mean 'std::isinf'?
164 | return isinf(result) ? copysignf(127.0f, result) : result;
| ^~~~~
| std::isinf
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:605:5: note: 'std::isinf' declared here
605 | isinf(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h: In function 'float volk_arctan(float)':
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:308:9: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
308 | if (isnan(x)) {
| ^~~~~
| std::isnan
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:632:5: note: 'std::isnan' declared here
632 | isnan(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:313:9: error: 'isinf' was not declared in this scope; did you mean 'std::isinf'?
313 | if (isinf(x)) {
| ^~~~~
| std::isinf
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:605:5: note: 'std::isinf' declared here
605 | isinf(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h: In function 'float volk_atan2(float, float)':
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:341:9: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
341 | if (isnan(x) || isnan(y)) {
| ^~~~~
| std::isnan
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:632:5: note: 'std::isnan' declared here
632 | isnan(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:346:9: error: 'isinf' was not declared in this scope; did you mean 'std::isinf'?
346 | if (isinf(y)) {
| ^~~~~
| std::isinf
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:605:5: note: 'std::isinf' declared here
605 | isinf(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:356:9: error: 'isinf' was not declared in this scope; did you mean 'std::isinf'?
356 | if (isinf(x)) {
| ^~~~~
| std::isinf
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:605:5: note: 'std::isinf' declared here
605 | isinf(_Tp __x)
| ^~~~~
In file included from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:19,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_common.h:369:9: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
369 | if (isnan(input)) {
| ^~~~~
| std::isnan
In file included from /usr/include/g++/complex:44,
from /tmp/work/math/volk/work/volk-3.3.0/include/volk/volk_complex.h:32,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk_typedefs.h:18,
from /tmp/work/math/volk/work/volk-3.3.0/cmake-pkgsrc-build/include/volk/volk.h:17,
from /tmp/work/math/volk/work/volk-3.3.0/lib/qa_utils.h:14,
from /tmp/work/math/volk/work/volk-3.3.0/lib/kernel_tests.h:11,
from /tmp/work/math/volk/work/volk-3.3.0/lib/testqa.cc:18:
/usr/include/g++/cmath:632:5: note: 'std::isnan' declared here
632 | isnan(_Tp __x)
| ^~~~~
ninja: build stopped: subcommand failed.
*** Error code 1
Stop.
make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/math/volk
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/math/volk
Subscribe to:
Comments (Atom)