Summary: | dev-util/source-highlight-3.1.8 fails to check for boost::regex in EPREFIX | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Olivier Huber <oli.huber> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Olivier Huber
2019-04-02 15:29:10 UTC
hmmm, I built this today just fine (gdb, eh?), so it probably has to do with your glibc version. Which is seriously odd, since RAP is supposed to provide that one, so you shouldn't be the only one. (In reply to Fabian Groffen from comment #1) > hmmm, I built this today just fine (gdb, eh?), so it probably has to do with > your glibc version. Which is seriously odd, since RAP is supposed to > provide that one, so you shouldn't be the only one. For me, the main issue is that during configure, the boost from the HOST is used, rather than the PREFIX. Sorry it wasn't super clear in my report. there's -I/usr/include in your post, so yeah, it seems to pick up wrong stuff Bumping EAPI to 7 and adding --with-boost="${ESYSROOT}"/usr \ to the econf call enables me to build it My understanding is that in the package provided ax_boost_base.m4, whenever no path is given to --with-boost, it looks into some hard-coded paths. If a path is provided to --with-boost, then it gets searched first. That's how BOOST_CPPFLAGS ends up being set to "/usr/include" and passed to the compiler. Actually even passing a garbage value as argument to --with-boost ends up solving the issue. Note that in my system-wide ax_boost_base.m4 file, there is the same issue: === AS_IF([test "x$_AX_BOOST_BASE_boost_path" != "x"],[ AC_MSG_CHECKING([for boostlib >= $1 ($WANT_BOOST_VERSION) includes in "$_AX_BOOST_BASE_boost_path/include"]) AS_IF([test -d "$_AX_BOOST_BASE_boost_path/include" && test -r "$_AX_BOOST_BASE_boost_path/include"],[ AC_MSG_RESULT([yes]) BOOST_CPPFLAGS="-I$_AX_BOOST_BASE_boost_path/include" for _AX_BOOST_BASE_boost_path_tmp in $multiarch_libsubdir $libsubdirs; do AC_MSG_CHECKING([for boostlib >= $1 ($WANT_BOOST_VERSION) lib path in "$_AX_BOOST_BASE_boost_path/$_AX_BOOST_BASE_boost_path_tmp"]) AS_IF([test -d "$_AX_BOOST_BASE_boost_path/$_AX_BOOST_BASE_boost_path_tmp" && test -r "$_AX_BOOST_BASE_boost_path/$_AX_BOOST_BASE_boost_path_tmp" ],[ AC_MSG_RESULT([yes]) BOOST_LDFLAGS="-L$_AX_BOOST_BASE_boost_path/$_AX_BOOST_BASE_boost_path_tmp"; break; ], [AC_MSG_RESULT([no])]) done],[ AC_MSG_RESULT([no])]) ],[ if test X"$cross_compiling" = Xyes; then search_libsubdirs=$multiarch_libsubdir else search_libsubdirs="$multiarch_libsubdir $libsubdirs" fi for _AX_BOOST_BASE_boost_path_tmp in /usr /usr/local /opt /opt/local ; do if test -d "$_AX_BOOST_BASE_boost_path_tmp/include/boost" && test -r "$_AX_BOOST_BASE_boost_path_tmp/include/boost" ; then for libsubdir in $search_libsubdirs ; do if ls "$_AX_BOOST_BASE_boost_path_tmp/$libsubdir/libboost_"* >/dev/null 2>&1 ; then break; fi done BOOST_LDFLAGS="-L$_AX_BOOST_BASE_boost_path_tmp/$libsubdir" BOOST_CPPFLAGS="-I$_AX_BOOST_BASE_boost_path_tmp/include" break; fi done ]) === Hence, whenever no path is given to --with-boost, "/usr /usr/local /opt /opt/local" gets searched for a include/boost , and used if successful. Hence, all packages using autotools and depending on boost will have some potential issue, unless --with-boost is given an argument. ACK, a fix like that is indeed the way to go (In reply to Olivier Huber from comment #4) > Bumping EAPI to 7 and adding > --with-boost="${ESYSROOT}"/usr \ > to the econf call enables me to build it Although not sure about cross compiling - which you don't seem to use, EAPI 7 doesn't feel necessary, as this most likely should read --with-boost="${EPREFIX}"/usr which should work for any EAPI, including EAPI 7. (In reply to Michael Haubenwallner from comment #6) > (In reply to Olivier Huber from comment #4) > > Bumping EAPI to 7 and adding > > --with-boost="${ESYSROOT}"/usr \ > > to the econf call enables me to build it > > Although not sure about cross compiling - which you don't seem to use, > EAPI 7 doesn't feel necessary, as this most likely should read > --with-boost="${EPREFIX}"/usr > which should work for any EAPI, including EAPI 7. I'm not crosscompiling, I just thought that this would be the more general fix, and would with non negligible probability cover the XC case :) For this particular package, I'm unsure whether supporting XC is relevant ... I am fine with both options. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8469a591901645a4be35330c24b9a802cc2a40d4 commit 8469a591901645a4be35330c24b9a802cc2a40d4 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2019-04-09 09:48:10 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2019-04-09 09:48:10 +0000 dev-util/source-highlight: fix build for Prefix, thanks Olivier Huber Closes: https://bugs.gentoo.org/682330 Signed-off-by: Fabian Groffen <grobian@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11 dev-util/source-highlight/source-highlight-3.1.8.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) |