Arch Linux User Repository

FYI, the compilation errors below have been fixed for some time upstream.

I got past the compiler error by adding

#include <boost/regex/pending/unicode_iterator.hpp>

to src/graph/gml.hh, directly after #include <boost/spirit/include/support_istream_iterator.hpp>

Someone needs to file a bug report upstream.

Could not make package. Compiler errors:

In file included from src/graph/graph_io.cc:40:
src/graph/gml.hh: In function 'bool graph_tool::read_gml(std::istream&, Graph&, boost::dynamic_properties&, const std::unordered_set<std::__cxx11::basic_string<char> >&, const std::unordered_set<std::__cxx11::basic_string<char> >&, const std::unordered_set<std::__cxx11::basic_string<char> >&)':
src/graph/gml.hh:367:5: error: 'u8_to_u32_iterator' was not declared in this scope
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |     ^~~~~~~~~~~~~~~~~~
src/graph/gml.hh:367:48: error: expected primary-expression before '>' token
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |                                                ^
src/graph/gml.hh:367:50: error: there are no arguments to 'tbegin' that depend on a template parameter, so a declaration of 'tbegin' must be available [-fpermissive]
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |                                                  ^~~~~~
src/graph/gml.hh:367:50: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
src/graph/gml.hh:367:65: error: there are no arguments to 'tend' that depend on a template parameter, so a declaration of 'tend' must be available [-fpermissive]
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |                                                                 ^~~~
src/graph/gml.hh:370:23: error: 'tbegin' was not declared in this scope; did you mean 'begin'?
  370 |         parse_grammar(tbegin, tend, g, dp,
      |                       ^~~~~~
      |                       begin
src/graph/gml.hh:370:31: error: 'tend' was not declared in this scope; did you mean 'end'?
  370 |         parse_grammar(tbegin, tend, g, dp,
      |                               ^~~~
      |                               end
src/graph/gml.hh: In instantiation of 'bool graph_tool::read_gml(std::istream&, Graph&, boost::dynamic_properties&, const std::unordered_set<std::__cxx11::basic_string<char> >&, const std::unordered_set<std::__cxx11::basic_string<char> >&, const std::unordered_set<std::__cxx11::basic_string<char> >&) [with Graph = boost::adj_list<long unsigned int>; std::istream = std::basic_istream<char>]':
src/graph/graph_io.cc:341:33:   required from here
src/graph/gml.hh:367:56: error: 'tbegin' was not declared in this scope; did you mean 'begin'?
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |                                                  ~~~~~~^~~~~~~
      |                                                  begin
src/graph/gml.hh:367:69: error: 'tend' was not declared in this scope; did you mean 'end'?
  367 |     u8_to_u32_iterator<spirit::istream_iterator> tbegin(begin), tend(end);
      |                                                                 ~~~~^~~~~
      |                                                                 end
make[1]: *** [Makefile:3908: src/graph/graph_io.lo] Error 1

I've incorporated your suggestion, which indeed is enough to prevent the runtime errors.

I've investigated further and found the source of the problem. It's entirely innocuous, and the vector access in question would be completely optimized away if it weren't for the assert itself. 🤦

I've fixed it upstream, but I will keep this fix here, since I don't understand why asserts should be turned on by default in production code. The assert that fails here is evoked in every vector access!!! I'm glad the user got an error instead of a super slow code... Otherwise this performance regression would have passed unnoticed.

@count0 OK, I've got it. In that case, I propose the following which removes the one flag from default /etc/makepkg.conf which triggers the assertions:

# disable assertions which lead to runtime failures
CXXFLAGS=${CXXFLAGS/-Wp,-D_GLIBCXX_ASSERTIONS/}
export CXXFLAGS="$CXXFLAGS -flto=auto -fno-fat-lto-objects"

Those assertion errors still indicate an error, though. Some code in graph-tool or boost-python or something is most likely abusing the STL. Has anyone reported the issue?

@count0 Thanks for the patch; I just successfully rebuilt from the AUR and do not get STL assertion errors anymore.

@lahwaacz Building the package is not the issue — the problem here are the arbitrary assertion errors that come from within STL code. Take a look at the example from @johnabs below. Are you able to reproduce this error?

@count0: Your change completely disregards all CXXFLAGS set in /etc/makepkg.conf which goes against the Arch package guidelines. Can you explain the "pollution" and which flags actually make the build fail?

FWIW, I just successfully built the package before the last change (using a clean chroot), which resulted in these flags being used:

Extra CXXFLAGS:         -fopenmp -O3 -fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated -Wall -Wextra -ftemplate-backtrace-limit=0 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -flto=auto -fno-fat-lto-objects

The problems below are due to the pollution of CXXFLAGS with some unnecessary and destructive flags. I've pushed a new version of the package the prevents this from happening. Please test!

Confirming that I am getting the same assertion failure as @johnabs and @chmue with the AUR version and that a git build works.