Arch Linux User Repository

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.

I tried building this package and ran into the same issues as @johnabs: The compilation would finish without errors but when I run the block model test code from below, it would give the same assertion error. I also tried removing the LTO CXXFLAGS as suggested here and reran makepkg but the error with the block model code was still there.

I proceeded to build the package directly from git (without makepkg):

git clone https://git.skewed.de/count0/graph-tool.git
cd graph-tool
./autogen.sh
./configure
make
make DESTDIR="~/.local/" install

The block model works after this!

YMMV (and you want to adjust DESTDIR) but I got it to work like this. The "issue" might stem from additional CXXFLAGS which are added by makepkg to make the executable more stable and safer to use so building directly from git does not "solve" the problem. I hope it helps if you desperately need to get the package to work (like me) and maybe as a hint to look into CXXFLAGS as the root of the issue.

Config snippet with flags:

Extra CXXFLAGS:         -fopenmp -O3 -fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated -Wall -Wextra -ftemplate-backtrace-limit=0 -g -O2

Okay, I tried rebuilding without LTO (twice for good measure). Here's the configuration summary, the only thing I changed in the pkgbuild was line 24 and removed the following: -flto=auto -fno-fat-lto-objects.

One thing I noticed was that in the config summary the -DNDEBUG flag was enabled, but I didn't do this, and apparently this is an issue according to count0's initial comment on this issue.

count0, just to make sure, is your build system fully up-to-date, and did you clear your pacman cache before doing your latest test build with the most recent pkgbuild file on the aur? I just want to make sure we can rule out everything that could by different and causing such an issue, as at this stage, I've done everything I can think of to isolate the issue and with no success, I'm guessing due to the fact that I am not an expert on C++.

If there is any other information I can provide, please let me know. According to npfeiler, apparently this issue is reproducible, though the fix he suggested didn't work for me (unless I failed to implement it properly).

================================================================================
                             CONFIGURATION SUMMARY
================================================================================
Using python version:   3.10.6
Python interpreter:     /usr/bin/python
Installation path:      /usr/lib/python3.10/site-packages/graph_tool

C++ compiler (CXX):     g++
C++ compiler version:   12.2.0

Prefix:                 /usr
Pkgconfigdir:           ${libdir}/pkgconfig

Python CPP flags:       -I/usr/lib/python3.10/site-packages/cairo/include -I/usr/include/python3.10
Python LD flags:        -L/usr/lib -lpython3.10
Boost CPP flags:        -pthread -I/usr/include
Boost LD flags:         -L/usr/lib64 -lboost_iostreams -lboost_python310 -lboost_regex -lboost_context -lboost_coroutine
Numpy CPP flags:        -I/usr/lib/python3.10/site-packages/numpy/core/include
Sparsehash CPP flags:
CGAL CPP flags:         -I/usr/include
CGAL LD flags:
Expat CPP flags:
Expat LD flags:          -lexpat
Cairomm CPP flags:      -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -pthread -I/usr/include/pixman-1
Cairomm LD flags:       -lcairomm-1.0 -lsigc-2.0 -lcairo
OpenMP compiler flags:  -fopenmp
OpenMP LD flags:
Extra CPPFLAGS:         -DNDEBUG
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
Extra LDFLAGS:

Using OpenMP:           yes
Using sparsehash:       yes
Using cairo:            yes
================================================================================

Just a heads up; I fully updated arch, reinstalled graph tool and tried again, and I'm still getting the same error :/

Edit: Thanks npfeiler, I misread can as can't. I'll try disabling LTO and rebuilding, and I'll let you know what I get. Could you let me know what changes you made to the pkgbuild to disable it? Is it just -flto=false?