Arch Linux User Repository

@lahwaacz that's great news! I've added the LICENSE file. Please let me know if any assistance is needed.

I would like to move this package to the Arch Linux extra repository. Can you add a 0BSD license to this repository (affecting the PKGBUILD) that we need according to RFC 0040?

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