Error checking version boostlib

[entermix]

I am trying to install an extension Gearman:

Operating System: Centos 7
PHP: 5.6.28

Perform the following steps:

wget https://launchpad.net/gearmand/1.2/1.1.11/+download/gearmand-1.1.12.tar.gz
tar -zxvf gearmand-1.1.12.tar.gz
cd gearmand-1.1.12
./configure

However, getting the error:
checking for boostlib> = 1.39 ... configure: We could not detect the boost libraries (version 1.39 or higher). If you have a staged boost library (still not installed) please specify $ BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost / version.hpp>. See http://randspringer.de/boost for more documentation.
configure: error: could not find boost

More details: http://pastebin.com/NFpbq20c

However, I have set BOOST 1.53

cat /usr/include/boost/version.hpp | grep "BOOST_LIB_VERSION"
//  BOOST_LIB_VERSION must be defined to be the same as BOOST_VERSION
#define BOOST_LIB_VERSION "1_53"

Why is this happening and how can I fix this?

[esabol]

First off, if you are going to compile gearmand from source, you might as well get the latest version, which you can download from https://github.com/gearman/gearmand/releases

Secondly, if you used yum to install boost, you probably didn't install the "devel" package. Try "sudo yum install boost-devel.x86_64" or similar.

[gmr]

FWIW I see this same issue when compiling from scratch, using Alpine Linux:

checking for boostlib >= 1.39... configure: We could not detect the boost libraries (version 1.39 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option.  If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.
configure: error: could not find boost

/tmp/gearmand-1.1.14 # cat /usr/include/boost/version.hpp  |grep BOOST_LIB_VERSION
//  BOOST_LIB_VERSION must be defined to be the same as BOOST_VERSION
#define BOOST_LIB_VERSION "1_60"

[esabol]

The existence of /usr/include/boost/version.hpp doesn't mean you have everything you need to compile programs that use boost.

On Alpine Linux, I think you need the boost-dev package in addition to the boost package.

[gmr]

I had installed it. I ended up finding out that someone's already packaged it in their testing repo. To get it installed, I do the following now:

echo "@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories
apk add --update gearmand@testing gearman-dev@testing

Here is the repo with what they patched and the compilation options for the curious:

http://git.alpinelinux.org/cgit/aports/tree/testing/gearmand?id=668180c0ce66281b7bb9b307d1130585b7d7cb87

[esabol]

They didn't do anything special except install the boost-dev package, which is what I suggested. Anyway, glad you found a solution.

[BasBastian]

Hi. Did you try boost-program-options or similar package?

https://www.rpmfind.net/linux/rpm2html/search.php?query=boost-program-options

That is usually missing from dependencies downloaded before building and causes make prematurely assume that libboost dependency has been resolved, which is not true.

[SpamapS]

Bump. I am not sure if we can do anything for this one. Feels like maybe a dead issue.

[drook]

There's clearly something broken in autotools-generated scripts, especially in the configure itself around line 17342, where configure is desperately trying to figure out where boost libraries are. This was working in 1.1.11, but this is broken from 1.1.12 to 1.1.18 (most recent as of now). I was being able to build gearman on Solaris with boost 1.55-1.66 (any version) by patching the configure of the 1.1.18 like this:

adding "BOOSTLIBDIR=/usr/local/boost/lib" (mine boost was installed in custom prefix) after line "if test "x$ax_boost_user_program_options_lib" = "x"; then". But this is purely hackish way of dealing with it, so I think the autotools templates that the configure is generated from should be patched or reconsidered.

[carpii]

I had the same issue compiling 1.1.12
boost-devel was installed but wasn't being detected, even when I pass --with-boost

For whatever reason installing these packages allowed it to compile

yum install gcc-c++.x86_64 gperf

[SpamapS]

Why would you be compiling 1.1.12? We're up to 1.1.18 now. Quoting carpii (2019-02-02 12:14:06)

…

I had the same issue compiling 1.1.12 boost-devel was installed but wasn't being detected, even when I pass --with-boost For whatever reason installing these packages allowed it to compile yum install gcc-c++.x86_64 gperf — You are receiving this because you commented. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread. References 1. #68 (comment) 2. https://github.com/notifications/unsubscribe-auth/AAcvYCnKQEon7JiG3760-x92IsRA-qgfks5vJfGOgaJpZM4LUedJ

[carpii]

Why would you be compiling 1.1.12? We're up to 1.1.18 now

Understood, but the note above does say that 1.18 is affected also
I did try compiling 1.18 first, but hit a whole bunch of problems different to compiling 1.12 (also this is what my dev server currently uses).

My note was more to help people in a similar situation than a bug report as such

[easterism]

I've got the same error for version 1.1.19
Debian GNU/Linux 10 (buster)

checking for boostlib >= 1.39... configure: We could not detect the boost libraries (version 1.39 or higher)

at the same time

libboost-all-dev is already the newest version (1.67.0.1).

[esabol]

I've got the same error for version 1.1.190
Debian GNU/Linux 10 (buster)

Hello! This issue probably should've been closed previously. I would call this a new issue since CentOS 7 and Debian 10 are very different, but, hey, we're here now. 😄

Unfortunately, I don't have a Dockerfile for building gearmand on Debian, so I don't have a solution ready. I don't have a Debian system readily available, and I don't have any real experience using Debian (everything is RHEL/CentOS with some Ubuntu where I work). We should probably add Debian to our CI workflow though.

Are you willing to help with debugging this, @easterism ? Maybe try compiling from the GitHub master branch source? The first thing I'd probably recommend trying is updating m4/ax_boost_base.m4 to a newer version before generating the configure script.

[esabol]

Wait, are you actually compiling 1.1.19 and not 1.1.19.1? If so, you definitely want to download the 1.1.19.1 release source code. 1.1.19 wasn't packaged correctly for release and should be avoided.

The Debian package description lists the following build dependencies:

Build-Depends: autoconf, automake, chrpath, debhelper-compat (= 10),
 default-libmysqlclient-dev, gperf, lcov, libboost-program-options-dev,
 libboost-system-dev, libboost-thread-dev, libcurl4-gnutls-dev, libevent-dev,
 libhiredis-dev, libltdl-dev, libmemcached-dev, libpq-dev, libsasl2-dev,
 libsqlite3-dev, libtool, memcached, pkg-config, procps, python3-sphinx,
 sharness, systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc s390],
 uuid-dev

Not sure if that's for Debian 10 or not, but are you sure you have all of those installed? You'd think libboost-all-dev would cover everything, but maybe it doesn't....

Is there a reason why you want to compile from source instead of using the Debian package?

https://packages.debian.org/bullseye/gearman-job-server

[easterism]

@esabol I did it for master (1.1.19.1 for now) as well, same result.
Btw, on another Debian 8 it run quite well...

Is there a reason why you want to compile from source instead of using the Debian package?

no special reason, but i stuck with strange issue (like #343). Conditions: Debian package 1.1.18+ds single server at the same host, 3 workers, very rare usage. Suddenly php client wont connect. I checking gearadmin --status (every second)

• first sec. OK, list of workers, no queue
• next sec. OK, list of workers, no queue
• next sec. OK, list of workers, no queue
• next sec. OK, list of workers, no queue
• next sec. STUCK, no output untill Ctrl+C

I've no idea why it happens but reinstall gearman-job-server temporarly help. Next 1-2 day it works well, but next sh... happens again.

So I hope compile from source will help... but I've no success yet

P.S. Its all about production server. On my dev server with completly same condition it works well. So looks like its a kind of magic :)

[esabol]

I did it for master (1.1.19.1 for now) as well, same result.
Btw, on another Debian 8 it run quite well...

Well, you didn't answer my question in my previous post:

The Debian package description lists the following build dependencies:

Build-Depends: autoconf, automake, chrpath, debhelper-compat (= 10),
 default-libmysqlclient-dev, gperf, lcov, libboost-program-options-dev,
 libboost-system-dev, libboost-thread-dev, libcurl4-gnutls-dev, libevent-dev,
 libhiredis-dev, libltdl-dev, libmemcached-dev, libpq-dev, libsasl2-dev,
 libsqlite3-dev, libtool, memcached, pkg-config, procps, python3-sphinx,
 sharness, systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc s390],
 uuid-dev

Not sure if that's for Debian 10 or not, but are you sure you have all of those (packages) installed?

Answering that question is step 1.

[easterism]

You'd think libboost-all-dev would cover everything, but maybe it doesn't...

Right, it doesn't!

apt install autoconf automake chrpath debhelper-compat help me run .configure correctly

apt install python3-sphinx help to make.

@esabol thank you again!