infomap.cc: error: 'isnan' was not declared in this scope; did you mean 'std::isnan' #669

barracuda156 · 2023-02-11T00:29:12Z

This error appeared in 1.4.0, earlier version built fine.

core/community/infomap/infomap.cc: In function 'int igraph_community_infomap(const igraph_t*, const igraph_vector_t*, const igraph_vector_t*, int, igraph_vector_t*, igraph_real_t*)':
core/community/infomap/infomap.cc:289:24: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
  289 |             } else if (isnan(minweight)) {
      |                        ^~~~~
      |                        std::isnan
In file included from /opt/local/include/LegacySupport/cmath:54,
                 from core/community/infomap/infomap.cc:32:
/opt/local/include/gcc12/c++/cmath:632:5: note: 'std::isnan' declared here
  632 |     isnan(_Tp __x)
      |     ^~~~~
core/community/infomap/infomap.cc:304:24: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
  304 |             } else if (isnan(minweight)) {
      |                        ^~~~~
      |                        std::isnan
/opt/local/include/gcc12/c++/cmath:632:5: note: 'std::isnan' declared here
  632 |     isnan(_Tp __x)
      |     ^~~~~
make: *** [core/community/infomap/infomap.o] Error 1
ERROR: compilation failed for package ‘igraph’

@szhorvat Somewhat unexpected breakage, but I should have tested earlier.

The text was updated successfully, but these errors were encountered:

szhorvat · 2023-02-11T09:25:41Z

I've already fixed this yesterday because of this and I'll submit a fix to MacPorts as well.

However, my understand was that this issue should only occur with GCC 5 and earlier. It seems you are using GCC 12. I'm not even sure how to do this, as using port -v install R-igraph +gcc12 still ends up using clang-14 on my macOS 10.14 system.

Can you give complete instructions for reproducing this?

barracuda156 · 2023-02-11T09:55:55Z

I've already fixed this yesterday because of this and I'll submit a fix to MacPorts as well.

However, my understand was that this issue should only occur with GCC 5 and earlier. It seems you are using GCC 12. I'm not even sure how to do this, as using port -v install R-igraph +gcc12 still ends up using clang-14 on my macOS 10.14 system.

Can you give complete instructions for reproducing this?

The R portgroup is set to use the same compiler which is used to build R. So you need to set libcxx to libstdc++ and use gcc to build R. Then the same settings can be used for R packages.

On PowerPC that is the default, but I have the same setup on 10.6.8 x86_64, without any clangs, only gcc.

szhorvat · 2023-02-11T11:18:20Z

I tried to compile R/igraph 1.4.0, as it is now on CRAN, using GCC 12, independently of MacPorts, but I cannot reproduce the issue. Nor do I see any way for this to occur with GCC 6 or later.

Here are the complete details:

I'm on macOS 10.14.6, using the official R binary distribution from https://www.r-project.org/, version 4.2.2 (i.e. not R from MacPorts).

For this experiment, this is the contents of my ~/.R/Makevars file:

CCACHE=
CC = $(CCACHE) /opt/local/bin/gcc-mp-12
CXX = $(CCACHE) /opt/local/bin/g++-mp-12
CXX11 = $(CCACHE) /opt/local/bin/g++-mp-12
FC = $(CCACHE) /opt/local/bin/gfortran-mp-12
F77 = $(CCACHE) /opt/local/bin/gfortran-mp-12
FLIBS = -L/opt/local/lib/libgcc -lgfortran -lquadmath -lm -Wl,-rpath /opt/local/lib/gcc12
CPPFLAGS=-I/opt/local/include
LDFLAGS=-L/opt/local/lib

This is meant to force R to use GCC 12 from MacPorts. It seems that specifying CXX11 (in addition to CXX) is now necessary.

Then in R, I run install.packages('igraph', type='source'). In the output, I check that both the C and C++ compilers that are used are what I expect:

checking for gcc... /opt/local/bin/gcc-mp-12
checking whether the C compiler works... yes
...
checking whether /opt/local/bin/g++-mp-12 -std=gnu++11 accepts -g... yes
checking for /opt/local/bin/g++-mp-12 -std=gnu++11 option to enable C++11 features... none needed

and also later I can see that /opt/local/bin/gcc-mp-12 and /opt/local/bin/g++-mp-12 are used.

I cannot reproduce the issue this way.

Now let's go back to MacPorts and do sudo port -v install R +gcc12. Looking at the ./configure output, I see this:

R is now configured for x86_64-apple-darwin18.7.0

  Source directory:            .
  Installation directory:      /opt/local/Library/Frameworks

  C compiler:                  /opt/local/bin/clang-mp-14  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  Fortran fixed-form compiler: /opt/local/bin/gfortran-mp-12 -fno-optimize-sibling-calls -pipe -Os -m64

  Default C++ compiler:        /opt/local/bin/clang++-mp-14 -std=gnu++14  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++11 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++11  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++14 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++14  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++17 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++17  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++20 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++20  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  Fortran free-form compiler:  /opt/local/bin/gfortran-mp-12 -fno-optimize-sibling-calls -pipe -Os -m64
  Obj-C compiler:	       /opt/local/bin/clang-mp-14 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64 -fobjc-exceptions

It still uses clang-14 instead of gcc-12. So I cannot test this using MacPorts's R.

@barracuda156 Is it possible that when you encountered this problem, you were in fact using a GCC version older than 6?

What I am looking for here is to confirm that the issue does not occur with GCC 6 and later, or with Clang. If you can confirm this then I'll be confident that I understand the problem, and the fix will be in the next version.

barracuda156 · 2023-02-11T11:42:11Z

@szhorvat It is absolutely with gcc12, as you can see from the log. In fortran isnan is a part of ieee_arithmetic which is not supported on several archs and platforms. But igraph seems to use it in C. Then it is apparently a bug in the code.

It should be 100% reproducible in 10.6.8 Rosetta. It can be tested in VM with native build for ppc with gcc12.

I am pretty sure you get the same error on 10.5.8 with gcc7, which is the default compiler in Macports for < 10.

szhorvat · 2023-02-11T11:55:03Z

It should be 100% reproducible in 10.6.8 Rosetta.

I do not have access to such old OS X versions.

It is absolutely with gcc12, as you can see from the log.

Actually the log does not show the compiler call, only that /opt/local/include/gcc12/c++/cmath got included somehow.

However, my understanding is that the issue is in the headers. You can read more here:

https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think

Notice that the header mentioned in the error is actually /opt/local/include/LegacySupport/cmath, so the GCC 12 headers are not being used indirectly. Maybe it's a problem with LegacySupport header.

Then it is apparently a bug in the code.

I do not believe this is an issue in igraph. Here's a minimal example that demonstrates the problem in GCC 5 and earlier: https://godbolt.org/z/dodzqacGs You can try this on your system to see if it's a bug in the headers.

Compile the following using gcc -std=gnu++11:

#include <cmath>
#include <math.h>

int main() { isnan(1.0); return 0; }

This is valid code, and it should compile. isnan should be present in the global namespace when #include <math.h> is included. However, with GCC 5 and earlier, it only compiles if #include <cmath> is commented out.

All that said, a workaround will be included in igraph 1.4.1.

barracuda156 · 2023-02-11T14:22:58Z

@szhorvat I got an early flight tomorrow, so please allow me a day.

But hopefully we can resolve this issue, otherwise everything is broken on PPC.

If legacysupport got a bug, this is something in need of being fixed ASAP too.

For gcc version, Macports chooses gcc7 for <10 and gcc12 for >=10. I am pretty sure gcc can be used to build R and R ports on any macOS, but I can try once I am back home.

Generally speaking, builds with gcc should be tested for anything of importance. It is the only compiler universally supported.

P. S. It is fairly easy to install 10.6.8 in VM, but perhaps not worth it for a single case.

barracuda156 · 2023-02-11T22:41:21Z

@szhorvat UPD. So the fix is this, right? igraph/igraph@7b42197#commitcomment-100264931

barracuda156 · 2023-02-12T17:35:03Z

The same failure occurs on 10.6.8 x86_64, so it is not arch-related problem:

/opt/x86_64/bin/g++-mp-12 -std=gnu++14 -I"/opt/x86_64/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -DUSING_R -I. -Icore -Iinclude -Ivendor -I/opt/x86_64/include/libxml2 -DNDEBUG -DNTIMER -DNPRINT -DINTERNAL_ARPACK -DPRPACK_IGRAPH_SUPPORT -DIGRAPH_THREAD_LOCAL=/**/  -isystem/opt/x86_64/include/LegacySupport -I/opt/x86_64/include   -fPIC   -c core/community/infomap/infomap.cc -o core/community/infomap/infomap.o
core/community/infomap/infomap.cc: In function 'int igraph_community_infomap(const igraph_t*, const igraph_vector_t*, const igraph_vector_t*, int, igraph_vector_t*, igraph_real_t*)':
core/community/infomap/infomap.cc:289:24: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
  289 |             } else if (isnan(minweight)) {
      |                        ^~~~~
      |                        std::isnan
In file included from /opt/x86_64/include/LegacySupport/cmath:54,
                 from core/community/infomap/infomap.cc:32:
/opt/x86_64/include/gcc12/c++/cmath:632:5: note: 'std::isnan' declared here
  632 |     isnan(_Tp __x)
      |     ^~~~~
core/community/infomap/infomap.cc:304:24: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
  304 |             } else if (isnan(minweight)) {
      |                        ^~~~~
      |                        std::isnan
/opt/x86_64/include/gcc12/c++/cmath:632:5: note: 'std::isnan' declared here
  632 |     isnan(_Tp __x)
      |     ^~~~~
make: *** [core/community/infomap/infomap.o] Error 1
ERROR: compilation failed for package ‘igraph’
* removing ‘/opt/x86_64/var/macports/build/_opt_x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-igraph/R-igraph/work/destroot/opt/x86_64/Library/Frameworks/R.framework/Versions/4.2/Resources/library/igraph’
Command failed:  cd "/opt/x86_64/var/macports/build/_opt_x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-igraph/R-igraph/work/igraph" && /opt/x86_64/bin/R CMD INSTALL . --library=/opt/x86_64/var/macports/build/_opt_x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-igraph/R-igraph/work/destroot/opt/x86_64/Library/Frameworks/R.framework/Versions/4.2/Resources/library 
Exit code: 1
Error: Failed to destroot R-igraph: command execution failed

barracuda156 · 2023-02-12T18:01:05Z

Now let's go back to MacPorts and do sudo port -v install R +gcc12. Looking at the ./configure output, I see this:

R is now configured for x86_64-apple-darwin18.7.0

  Source directory:            .
  Installation directory:      /opt/local/Library/Frameworks

  C compiler:                  /opt/local/bin/clang-mp-14  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  Fortran fixed-form compiler: /opt/local/bin/gfortran-mp-12 -fno-optimize-sibling-calls -pipe -Os -m64

  Default C++ compiler:        /opt/local/bin/clang++-mp-14 -std=gnu++14  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++11 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++11  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++14 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++14  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++17 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++17  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  C++20 compiler:              /opt/local/bin/clang++-mp-14 -std=gnu++20  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
  Fortran free-form compiler:  /opt/local/bin/gfortran-mp-12 -fno-optimize-sibling-calls -pipe -Os -m64
  Obj-C compiler:	       /opt/local/bin/clang-mp-14 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64 -fobjc-exceptions

It still uses clang-14 instead of gcc-12. So I cannot test this using MacPorts's R.

@szhorvat (Sorry for sporadic replies, I am just back home today and sorting things out.)

There is no variant defined, so +gcc12 will be ignored. This should work:

sudo port -v -n build R configure.compiler=macports-gcc-12 configure.cxx_stdlib=libstdc++

Two caveats:

It may be still needed to add CXX fields into Makeconf manually though. On 10.6.8 fields were empty, when I built R with gcc12 for x86_64.
From initial try R build failed on Catalina: apparently some headers inside 10.15 SDK do not work with GCC or need some special treatment. I cannot say until which OS it works smoothly.

szhorvat · 2023-02-12T18:23:28Z

My suggestion is to just wait for 1.4.1, which replaces isnan() with igraph_is_nan(), so won't have this problem for certain.

It seems that the build did succeed on the MacPorts buildbots on all platforms that builds are produced for, inlcuding 10.6 i386 and x86_64: https://ports.macports.org/port/R-igraph/builds/

So this issue will affect very few people: only those who use a very old system, and choose a non-default compiler.

A separate issue is whether there's a problem with legacysupport. That should be investigated independently of igraph, using the small test problem I showed in this comment.

barracuda156 · 2023-02-12T18:34:38Z

My suggestion is to just wait for 1.4.1, which replaces isnan() with igraph_is_nan(), so won't have this problem for certain.

If it is coming soon, then sure.

It seems that the build did succeed on the MacPorts buildbots on all platforms that builds are produced for, inlcuding 10.6 i386 and x86_64: https://ports.macports.org/port/R-igraph/builds/

I think they all use Clang (in Macports), and the issue we are getting happens with GCC.

So this issue will affect very few people: only those who use a very old system, and choose a non-default compiler.

While I do not get obsession with Clang, using a non-default compiler is not a concern on my side (for that we would need far more than fixing a single port). But on PowerPC default compiler is GCC, and will remain GCC indefinitely (hopefully Macports will move from gcc7 to gcc12/13 across the board).

A separate issue is whether there's a problem with legacysupport. That should be investigated independently of igraph, using the small test problem I showed in this comment.

This is probably not something I can easily debug, I do not understand legacysupport workings that well. But if the same issue is encountered elsewhere, I will open a ticket for legacysupport cmath. So far, AFAIR, this is the only instance.

szhorvat · 2023-02-13T08:18:11Z

I'm going to close this now since the affected isnan() has been completely removed.

1.4.1, which will include the fix, is planned to be submitted soon.

barracuda156 · 2023-02-21T23:07:21Z

@szhorvat Maybe we could have a patch for now, instead of having everything broken? (igraph is a dependency for other ports.)

barracuda156 · 2023-02-22T06:43:57Z

And we got the same error with magick too:

In file included from /opt/local/include/ImageMagick-6/magick/MagickCore.h:78,
                 from /opt/local/include/ImageMagick-6/Magick++/Include.h:45,
                 from /opt/local/include/ImageMagick-6/Magick++.h:10,
                 from magick_types.h:3,
                 from RcppExports.cpp:4:
/opt/local/include/ImageMagick-6/magick/quantum.h: In function 'MagickCore::Quantum MagickCore::ClampToQuantum(MagickRealType)':
/opt/local/include/ImageMagick-6/magick/magick-type.h:220:20: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
  220 | #  define IsNaN(a) isnan(a)
      |                    ^~~~~
/opt/local/include/ImageMagick-6/magick/magick-type.h:220:20: note: in definition of macro 'IsNaN'
  220 | #  define IsNaN(a) isnan(a)
      |                    ^~~~~
In file included from /opt/local/include/LegacySupport/cmath:54,
                 from /opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:100,
                 from /opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include/Rcpp/r/headers.h:62,
                 from /opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include/RcppCommon.h:30,
                 from /opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include/Rcpp.h:27,
                 from magick_types.h:2:
/opt/local/include/gcc12/c++/cmath:632:5: note: 'std::isnan' declared here
  632 |     isnan(_Tp __x)
      |     ^~~~~
make: *** [RcppExports.o] Error 1

szhorvat · 2023-02-22T11:47:55Z

Maybe we could have a patch for now,

The update is already submitted to CRAN, but it takes time for it to go through the approval process. I don't have time to submit a special patch right now, but hopefully there'll be an 1.4.1 soon.

instead of having everything broken?

Maybe that's a bit of an overstatement, since this seems to affect only very old platforms used by a small minority of people. Note that 10.6 on i386 and x86_64 are not affected. Only PCC seems to be affected, or more generally: systems which use headers from GCC 5 or earlier.

barracuda156 · 2023-02-22T12:19:51Z

The update is already submitted to CRAN

Got it, sounds good.

Only PCC seems to be affected, or more generally: systems which use headers from GCC 5 or earlier.

IMO this is rather a problem of igraph+gcc+legacysupport (?) combo than of an arch. Macports, unfortunately, only tests with Clangs, so we have no idea what is going on with gcc builds. But it is not a problem exclusive to gcc5 (I won’t build gcc5 just to try, but for me these failures occur with gcc12).

barracuda156 mentioned this issue Feb 11, 2023

R-igraph: update to 1.4.0 macports/macports-ports#17661

Merged

12 tasks

szhorvat mentioned this issue Feb 11, 2023

CRAN release v1.4.0 #661

Merged

3 tasks

szhorvat closed this as completed Feb 13, 2023

barracuda156 mentioned this issue Feb 22, 2023

magick-type.h: error: 'isnan' was not declared in this scope; did you mean 'std::isnan'? ropensci/magick#369

Closed

github-actions bot locked and limited conversation to collaborators Mar 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

infomap.cc: error: 'isnan' was not declared in this scope; did you mean 'std::isnan' #669

infomap.cc: error: 'isnan' was not declared in this scope; did you mean 'std::isnan' #669

barracuda156 commented Feb 11, 2023

szhorvat commented Feb 11, 2023

barracuda156 commented Feb 11, 2023

szhorvat commented Feb 11, 2023 •

edited

barracuda156 commented Feb 11, 2023 •

edited

szhorvat commented Feb 11, 2023 •

edited

barracuda156 commented Feb 11, 2023

barracuda156 commented Feb 11, 2023 •

edited

barracuda156 commented Feb 12, 2023

barracuda156 commented Feb 12, 2023

szhorvat commented Feb 12, 2023 •

edited

barracuda156 commented Feb 12, 2023

szhorvat commented Feb 13, 2023

barracuda156 commented Feb 21, 2023

barracuda156 commented Feb 22, 2023

szhorvat commented Feb 22, 2023 •

edited

barracuda156 commented Feb 22, 2023

infomap.cc: error: 'isnan' was not declared in this scope; did you mean 'std::isnan' #669

infomap.cc: error: 'isnan' was not declared in this scope; did you mean 'std::isnan' #669

Comments

barracuda156 commented Feb 11, 2023

szhorvat commented Feb 11, 2023

barracuda156 commented Feb 11, 2023

szhorvat commented Feb 11, 2023 • edited

barracuda156 commented Feb 11, 2023 • edited

szhorvat commented Feb 11, 2023 • edited

barracuda156 commented Feb 11, 2023

barracuda156 commented Feb 11, 2023 • edited

barracuda156 commented Feb 12, 2023

barracuda156 commented Feb 12, 2023

szhorvat commented Feb 12, 2023 • edited

barracuda156 commented Feb 12, 2023

szhorvat commented Feb 13, 2023

barracuda156 commented Feb 21, 2023

barracuda156 commented Feb 22, 2023

szhorvat commented Feb 22, 2023 • edited

barracuda156 commented Feb 22, 2023

szhorvat commented Feb 11, 2023 •

edited

barracuda156 commented Feb 11, 2023 •

edited

szhorvat commented Feb 11, 2023 •

edited

barracuda156 commented Feb 11, 2023 •

edited

szhorvat commented Feb 12, 2023 •

edited

szhorvat commented Feb 22, 2023 •

edited