$python -c 'from graph_tool.all import *' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python3.3/site-packages/graph_tool/__init__.py", line 101, in <module> dl_import("from . import libgraph_tool_core as libcore") File "/usr/lib64/python3.3/site-packages/graph_tool/dl_import.py", line 57, in dl_import exec(import_expr, local_dict, global_dict) File "<string>", line 1, in <module> ImportError: /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE I found another instance of the same error message here: http://forums.gentoo.org/viewtopic-t-778706-view-next.html?sid=1ea38821e98f503f87aca8d5fe61ff8a Reproducible: Always Steps to Reproduce: 1. (eselect python3.3) 2. emerge graph-tool 3. python -c 'from graph_tool.all import *' Actual Results: ImportError: /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE Expected Results: import without error $emerge graph-tool (emerge completes without error) test: $/usr/bin/python3.3 Python 3.3.3 (default, Jan 23 2014, 08:25:03) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from graph_tool.all import * Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.3/site-packages/graph_tool/__init__.py", line 101, in <module> dl_import("from . import libgraph_tool_core as libcore") File "/usr/lib64/python3.3/site-packages/graph_tool/dl_import.py", line 57, in dl_import exec(import_expr, local_dict, global_dict) File "<string>", line 1, in <module> ImportError: /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE >>> /usr/bin/python2.7 Python 2.7.5 (default, May 17 2014, 17:40:42) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from graph_tool.all import * Killed That "Killed" prints in /var/log/messages: Jan 15 12:44:33 localhost kernel: [411218.468699] PAX: execution attempt in: (null), 00000000-00000000 00000000 Jan 15 12:44:33 localhost kernel: [411218.468711] PAX: terminating task: /usr/bin/python2.7(python2.7):13851, uid/euid: 1001/1001, PC: 0000000000166a76, SP: 0000038f6e928c38 Jan 15 12:44:33 localhost kernel: [411218.468714] PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Jan 15 12:44:33 localhost kernel: [411218.468730] PAX: bytes at SP-8: 000000652fca1640 000002ddab12b189 000000652f9b7a54 000002ddab3f85f8 0000000000001001 6e2889ad37b92000 000000652f9b7a54 000000652fca1640 000000652e6d6010 000000652f9a2718 000000652f9b7a54 Jan 15 12:44:33 localhost kernel: [411218.468754] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/python2.7[python2.7:13851] uid/euid:1001/1001 gid/egid:1001/1001, parent /bin/bash[bash:30070] uid/euid:1001/1001 gid/egid:1001/1001 (2.7 might be a different issue, my goal is to get py3.3 to work) $emerge --info boost graph-tool python Portage 2.2.14 (python 3.3.3-final-0, hardened/linux/amd64, gcc-4.8.3, glibc-2.17, 3.15.8-hardened x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.15.8-hardened-x86_64-Intel-R-_Xeon-R-_CPU_X5482_@_3.20GHz-with-gentoo-2.2 KiB Mem: 32955148 total, 695016 free KiB Swap: 33554428 total, 33176572 free Timestamp of tree: Thu, 15 Jan 2015 06:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.9 [enabled] app-shells/bash: 4.2_p53 dev-java/java-config: 2.2.0 dev-lang/perl: 5.16.3 dev-lang/python: 2.7.5-r3, 3.2.5-r3, 3.3.3 dev-util/ccache: 3.1.9-r3 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.6.3, 4.7.3-r1, 4.8.3, 4.9.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo poly-c local_overlay ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.mirrors.hoobly.com/ http://mirror.usu.edu/mirrors/gentoo/ ftp://gentoo.mirrors.tds.net/gentoo ftp://mirror.datapipe.net/gentoo" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/poly-c /usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X alisp alsa amd64 apng aspell berkdb bindist bzip2 cairo clang cli cpudetection cracklib crypt cryptsetup cups cxx device-mapper dga dri exif ffmpeg fftw fontconfig ftdi gcj gdbm geos gif glade glut gml gnuplot gps graphviz gtk3 gudev hardened helpers hwdb iconv icu imagemagick ipv6 ipython irqbalance jpeg jpeg2k justify keymap lapack latex lcms libkms lvm mad man mmx mmxext mng modules mp3 multilib ncat ncurses ndiff netcdf nls nping nptl ntfs numpy offensive ogg oog opengl openmp pam pax_kernel pcre pdf png postgres postscript pylint python qemu qt3support raw readline rtlsdr scipy sdl session smp smpeg spell spice sql sqlite sse sse2 ssl ssse3 svg tcpd threads tiff tinfo tools truetype unicode urandom usb v4l virt-network vorbis wavelet webkit wmf x264 xa xattr xcb xetex xpm xtpax xvfb xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="multipath crypt" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="nouveau intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.2 3.3" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= dev-libs/boost-1.55.0-r2 was built with the following: USE="icu nls python threads tools -context -debug -doc -mpi -static-libs" ABI_X86="64 -32 -x32" PYTHON_TARGETS="python2_7 python3_3 -python3_4" CXXFLAGS="-march=native -O2 -pipe -std=gnu++11" dev-python/graph-tool-2.2.36 was built with the following: USE="cairo openmp" ABI_X86="64" PYTHON_TARGETS="python2_7 python3_3 -python3_4" dev-lang/python-2.7.5-r3 was built with the following: USE="gdbm hardened ipv6 ncurses readline sqlite ssl threads tk (wide-unicode) xml -berkdb -build -doc -examples -wininst" ABI_X86="64" CFLAGS="-march=native -O2 -pipe -fwrapv" CXXFLAGS="-march=native -O2 -pipe -fwrapv" LDFLAGS="-Wl,-O1 -Wl,--as-needed -L." dev-lang/python-3.2.5-r3 was built with the following: USE="gdbm hardened ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -build -doc -examples -tk -wininst" ABI_X86="64" CFLAGS="-march=native -O2 -pipe -fwrapv" CXXFLAGS="-march=native -O2 -pipe -fwrapv" LDFLAGS="-Wl,-O1 -Wl,--as-needed -L." dev-lang/python-3.3.3 was built with the following: USE="gdbm hardened ipv6 ncurses readline sqlite ssl threads xml -build -doc -examples -tk -wininst" ABI_X86="64" CFLAGS="-march=native -O2 -pipe -fwrapv" CXXFLAGS="-march=native -O2 -pipe -fwrapv" LDFLAGS="-Wl,-O1 -Wl,--as-needed -L." $eselect python list Available Python interpreters: [1] python2.7 [2] python3.2 [3] python3.3 * What I tried: --------------------- I switched from GCC 4.7 to 4.8.3 following: http://wiki.gentoo.org/wiki/Upgrading_GCC emerge -1 boost emerge graph-tool $python -c 'from graph_tool.all import *' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python3.3/site-packages/graph_tool/__init__.py", line 101, in <module> dl_import("from . import libgraph_tool_core as libcore") File "/usr/lib64/python3.3/site-packages/graph_tool/dl_import.py", line 57, in dl_import exec(import_expr, local_dict, global_dict) File "<string>", line 1, in <module> ImportError: /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE (same error) After reading: The note about C++11 @ the bottom of http://graph-tool.skewed.de/download The comments by Tanner @ https://stackoverflow.com/questions/19865757/importerror-usr-lib-libboost-python-so-1-54-0-undefined-symbol-pyclass-type Then found a note in /usr/portage/dev-libs/boost/boost-1.55.0-r2.ebuild: # Do _not_ use C++11 yet, make sure to force GNU C++ 98 standard. append-cxxflags -std=gnu++98 I changed it to: append-cxxflags -std=gnu++11 re-generated the Manifest and then: $emerge -1 boost $revdep-rebuild --library X$(qlist -e boost | grep .so$ | xargs -n 1 printf "|%s") $python -c 'from graph_tool.all import *' (same error)
Note MAKEOPTS="${MAKEOPTS} -j1" is hard coded in graph-tool-2.2.36.ebuild, for testing I changed it to -j8 with 32G without issue.
$nm -D /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so | grep _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE U _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE $ldd -r /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so linux-vdso.so.1 (0x000002cf009d9000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/libstdc++.so.6 (0x000002cefed7c000) libpython3.3.so.1.0 => /usr/lib64/libpython3.3.so.1.0 (0x000002cefe8da000) libboost_iostreams.so.1.55.0 => /usr/lib64/libboost_iostreams.so.1.55.0 (0x000002cefe6bf000) libboost_python-2.7.so.1.55.0 => /usr/lib64/libboost_python-2.7.so.1.55.0 (0x000002cefe46f000) libboost_regex.so.1.55.0 => /usr/lib64/libboost_regex.so.1.55.0 (0x000002cefe162000) libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/libgomp.so.1 (0x000002cefdf47000) libCGAL.so.10 => /usr/lib64/libCGAL.so.10 (0x000002cefdd1b000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x000002cefdaed000) libbz2.so.1 => /lib64/libbz2.so.1 (0x000002cefd8dc000) libm.so.6 => /lib64/libm.so.6 (0x000002cefd5df000) libc.so.6 => /lib64/libc.so.6 (0x000002cefd233000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/libgcc_s.so.1 (0x000002cefd01b000) /lib64/ld-linux-x86-64.so.2 (0x000002cf009da000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000002cefcdfe000) libdl.so.2 => /lib64/libdl.so.2 (0x000002cefcbf9000) libutil.so.1 => /lib64/libutil.so.1 (0x000002cefc9f6000) libz.so.1 => /lib64/libz.so.1 (0x000002cefc7de000) librt.so.1 => /lib64/librt.so.1 (0x000002cefc5d5000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x000002cefc1f4000) libicuuc.so.52 => /usr/lib64/libicuuc.so.52 (0x000002cefbe74000) libicui18n.so.52 => /usr/lib64/libicui18n.so.52 (0x000002cefbc62000) libicudata.so.52 => /usr/lib64/libicudata.so.52 (0x000002cefa3f5000) libboost_thread.so.1.55.0 => /usr/lib64/libboost_thread.so.1.55.0 (0x000002cefa1db000) libboost_system.so.1.55.0 => /usr/lib64/libboost_system.so.1.55.0 (0x000002cef9fd6000) undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE (/usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so) $c++filt -n _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE boost::python::detail::init_module(PyModuleDef&, void (*)()) $nm -D /usr/lib64/libboost_python-3.3.so | grep _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE 0000000000036700 T _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE
Created attachment 394064 [details] build.log.gz note this is with -std=gnu++1
I verified via it's build log that graph-tool is being compiled with -std=gnu++11 (without changing the ebuild). By default, boost is not.
Created attachment 394066 [details] dev-python/graph-tool-2.2.36 build.log Notice that graph-tool is being compiled with -lboost_python-2.7-mt (everywhere) even though my system default is py3.3. I think "-lboost_python-2.7-mt" should be "-lboost_python" With this in mind, I edited the ebuild to remove py2.7 support completely: PYTHON_COMPAT=( python{3_3,3_4} ) and recompiled graph-tool. It's build log still shows it's using "-lboost_python-2.7-mt" only.
in: ./work/graph-tool-2.2.36-python3_3/config.log configure:18032: checking for exit in -lboost_python configure:18057: x86_64-pc-linux-gnu-g++ -o conftest -Wall -Wextra -Wno-unused-local-typedefs -Wno-unused-parameter -march=native -O2 -pipe -DNDEBUG -std=gnu++11 -ftemplate-depth-250 -Wno-deprecated -Wno-unknown-pragmas -fvisibility=default -fvisibility-inlines-hidden -fopenmp -I/usr/include/python3.3 -Wl,-O1 -Wl$ /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_python collect2: error: ld returned 1 exit status
Created attachment 394068 [details] boost_py_33_module.tar.gz On my system, "-lboost_python-3.3" works (test case attached). This may be related to bug 498552 graph-tool appears to be attempting to use -lboost_python when it should be using -lboost_python-3.3. The ./configure log shows it does not show a check for -lboost_python-3.3.
Created attachment 394082 [details, diff] graph-tool-2.2.36.ebuild.patch Patch attached, this fixed it for me.
(In reply to Justin Keogh from comment #8) > Created attachment 394082 [details, diff] [details, diff] > graph-tool-2.2.36.ebuild.patch > > Patch attached, this fixed it for me. inherit eutils check-reqs toolchain-funcs python-r1 sigh, I went to the effort of removing it and your trying to add it in again. fyi, eutils is implicitly inherited by python-r1. However, this is not so straight forward. There are devs who 'like' to explicitly inherit eclasses that are already implicitly inherited. So I guess both are right. I'm in the camp that says it's totally redundant and so I leave it out. The first attempt yielded a total system freeze, however on the 2nd attempt, ~/cvsPortage/gentoo-x86/dev-python/graph-tool $ time PYTHON_TARGETS=python3_3 ebuild graph-tool-2.2.36.ebuild clean install yields make[2]: Leaving directory '/mnt/gen2/TmpDir/portage/dev-python/graph-tool-2.2.36/work/graph-tool-2.2.36-python3_3' make[1]: Leaving directory '/mnt/gen2/TmpDir/portage/dev-python/graph-tool-2.2.36/work/graph-tool-2.2.36-python3_3' (delete unhelpful lines) >>> Completed installing graph-tool-2.2.36 into /mnt/gen2/TmpDir/portage/dev-python/graph-tool-2.2.36/image/ (delete more unhelpful lines) real 114m44.059s user 112m38.933s sys 2m45.857s with the ebuild untouched. I for 1 am not convinced that the ebuild is bugged.
Thanks, I agree. The problem has returned for me, please disregard my patch for now. I'll keep trying to get to the bottom of the problem. This issue returned for me today when I was trying to debug a segfault (caused by the command below), and I: updated boost to 1.56.0-r1 (may or may not be related) installed graph-tool-9999 (see https://bugs.gentoo.org/show_bug.cgi?id=536810) (note this specific problem, the undefined symbol, did not appear with 9999) re-installed graph-tool-2.2.36 (with the ebuild patched) I'd be interested to know if "/usr/bin/python3.3 -c 'import graph_tool.all as gt'" works for you. Thanks for the information about eutils being implicitly inherited by python-r1, I will remember that next time.
well; $ python3.3 -c 'import graph_tool.all as gt' yields python3.3: symbol lookup error: /usr/lib64/python3.3/site-packages/graph_tool/libgraph_tool_core.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE a true runtime error. however this is with 2.2.35 however I'd expect the same from 2.2.36. So the ebuild might work to build and install but a runtime error is something different again. Perhaps your patch has merit.
I mentioned in comment #10 that I tried 9999, and the undefined symbol problem didnt exist, and that was correct, but the 9999 ebuild was/is using a outdated git repo from July 2014. After fixing the get repo with bug 536826, I recompiled and now the same 'undefined symbol' error happens.
(In reply to Justin Keogh from comment #12) > I mentioned in comment #10 that I tried 9999, and the undefined symbol > problem didnt exist, and that was correct, but the 9999 ebuild was/is using > a outdated git repo from July 2014. > > After fixing the get repo with bug 536826, I recompiled and now the same > 'undefined symbol' error happens. and now for the bad news!! I think filing upstream would be apt here. If you don't or can't I can or redhermit
OK, I think I (finally) know what's going on. First, the ebuild is fine the way it is. No patch needed. The problem is upstream almost for sure, here is how I worked around it: $PYTHON_TARGETS="python3_3" emerge boost -1 this obviously installs boost without py2.7 support. then: $emerge graph-tool then during the graph-tool ./configure this will happen: configure:18032: checking for exit in -lboost_python-2.7 configure:18057: x86_64-pc-linux-gnu-g++ -o conftest -Wall -Wextra -Wno-unused-local-typedefs -Wno-unused-parameter -march=native -O2 -pipe -DNDEBUG -std=gnu++11 -ftemplate-depth-250 -Wno-deprecated -Wno-unknown-pragmas -fvisibility=default -fvisibility-inlines-hidden -fopenmp -I/usr/include/python3.3 -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -lpython3.3 conftest.cpp -lboost_python-2.7 -L/usr/lib64 -lpython3.3 -lexpat -lbz2 -lm >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_python-2.7 collect2: error: ld returned 1 exit status configure:18057: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "graph-tool" | #define PACKAGE_TARNAME "graph-tool" | #define PACKAGE_VERSION "2.2.36" | #define PACKAGE_STRING "graph-tool 2.2.36" | #define PACKAGE_BUGREPORT "http://graph-tool.skewed.de/tickets" | #define PACKAGE_URL "http://graph-tool.skewed.de" | #define PACKAGE "graph-tool" | #define VERSION "2.2.36" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define __EXTENSIONS__ 1 | #define _ALL_SOURCE 1 | #define _GNU_SOURCE 1 | #define _POSIX_PTHREAD_SEMANTICS 1 | #define _TANDEM_SOURCE 1 | #define STDC_HEADERS 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define USING_OPENMP 1 | #define HAVE_LIBM 1 | #define HAVE_LIBBZ2 1 | #define HAVE_LIBEXPAT 1 | #define HAVE_PYTHON "3.3" | #define HAVE_BOOST /**/ | #define HAVE_BOOST_PYTHON /**/ | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char exit (); | int | main () | { | return exit (); | ; | return 0; | } configure:18067: result: no configure:18032: checking for exit in -lboost_python-3-mt That error, seems to cause the last line "checking for exit in -lboost_python-3-mt" to run. With boost py2.7 support, the ./configure log never shows the -lboost_python-3-mt check. now: /usr/bin/python3.3 -c 'import graph_tool' (which also would previously error our with undefined symbol) works. $/usr/bin/python3.3 -c 'import graph_tool ; print(graph_tool.__version__)' 2.2.36 (commit e3865108, Thu Jan 8 17:03:44 2015 +0100) unfortunatly, the original test command segfauls: $/usr/bin/python3.3 -c 'from graph_tool.all import *' Segmentation fault $tail -n 1 /var/log/messages Jan 17 04:56:28 localhost kernel: [24767.038816] python3.3[28655]: segfault at 16ae76 ip 000000000016ae76 sp 00007fff0d7f0a48 error 14 in libgmp.so.10.1.3[7f0cb76f3000+78000] but that's likely a different bug. I'll contact upstream.
upstream contacted: http://thread.gmane.org/gmane.comp.science.graph.graph-tool.general/1789
well done Justin most impressive. It appears the recent form from upstream is py2 centric in its install of boost. Possibly a solution will need doing in the boost lib. This is out of more realm of usual practice, I think Mr. Harder might be better at this.
the comments from /1789 is not exactly inspiring. "but it seems to be failing in this case" is where it all ends. As for what they're going to do about it, well, nothing planned it seems. He just settles for passively observing the failure then, ...... To my understanding, his suggestion would make the build suddenly receptive to py3.3, but I anticipate it would then be insensitive to py2.7. You (??) fix 1 thing only to break another. My realm doesn't cover C C++ builds in depth, so I am not offering any final fix. In this case I will only comment that the configure script for the build fails to serve py2 and py3, but rather py2 OR py3. Hardly satisfactory for gentoo trying to provide multi impl. builds.
Created attachment 394322 [details, diff] graph-tool-2.2.36.ebuild.patch Thanks for the encouragement and help Ian, I think it's sorted out now, the attached patch makes all python versions work. Tested with (both 2.2.36 and 9999): $/usr/bin/python3.3 -c 'import graph_tool ; print(graph_tool.__version__)' 2.2.37dev (commit 201879ac, Fri Jan 9 15:46:17 2015 +0100) $/usr/bin/python2.7 -c 'import graph_tool ; print(graph_tool.__version__)' 2.2.37dev (commit 201879ac, Fri Jan 9 15:46:17 2015 +0100) I filed a duplicate bug 537034 for the 9999 version, the fix is the same, 9999 patch attached over there. Hat tip to #gentoo-dev-help
*** Bug 537034 has been marked as a duplicate of this bug. ***
well looks good however I shall leave the final commit to Mr. Harder. I wonder if the line --with-boost-python=${EPYTHON: -3}-mt could simply be added to the current content of src_configure() {. I am not clear whether this would suffice with use of python-r1 since it's an eclass I don't normally utilise, but the maintainer does. (You made a 'typo' with src_configure(){, a triviality. It works anyway I believe)
Do you mean the lack of the space in "src_configure_py(){"? I see that's different, adding to my mental checklist. I used a second function because when I added it to the current src_configure() ${EPYTHON} didnt re-evaluate for each version.
(In reply to Justin Keogh from comment #21) > Do you mean the lack of the space in "src_configure_py(){"? I see that's > different, adding to my mental checklist. > > I used a second function because when I added it to the current > src_configure() ${EPYTHON} didnt re-evaluate for each version. 1. yes. totally trivial. 2. In that case your patch looks spot on
(In reply to Ian Delaney from comment #22) > 2. In that case your patch looks spot on Not quite, you're assuming everyone has boost built with threads enabled. Anyway, this should now be fixed in 2.2.36-r1 and the live ebuild.
I should also note that this should really be handled in the boost-python m4 script, but we can hack around it for now.
