Can't build cleanly on Ubuntu 18.04

[SpamapS]

In trying to make a release from the commits since 1.1.18, I have run in to a number of build and test failures. Wondering if anyone else has them. Specifically,

1. can't find libpq-fe.h, despite having libpq-dev installed (build is fine when --without-postgresql is used)
2. t/unittest fails for some unknown reason

I don't really have the time to debug deeply.. hoping somebody has some cycles to get through this and confirm that things work on Ubuntu 18.04.

[esabol]

For what it’s worth, I would like to see PR #257 included in the next release.

[esabol]

Here's the unittest failure:

libtest/unittest.cc:663: in application_doesnotexist_BINARY() pid(23963) Assertion 'Application::SUCCESS' != 'true_app.run(args)'
unittest.application.doesnotexist --fubar                                       [ failed ]

[esabol]

I'm not seeing any error with regards to libpq-fe.h, but the postgres test is being skipped for some reason I haven't yet been able to figure out.

# gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0

Here's the Dockerfile I'm using to test:

FROM ubuntu:18.04

ARG GEARMAN_REPO=https://github.com/gearman/gearmand

# Configure environment
ENV DEBIAN_FRONTEND=noninteractive \
    TZ=America/New_York \
    HOME=/root

# Install packages
RUN apt-get update \
 && apt-get -y upgrade \
 && apt-get -y install \
        automake \
        autoconf \
        libtool \
        make \
        curl \
        gcc \
        g++ \
        git \
        gperf \
        libboost-all-dev \
        libevent-dev \
        libhiredis-dev \
        libssl-dev \
        libpq-dev \
        libtokyocabinet-dev \
        tcsh \
        python3-sphinx \
        uuid-dev \
        wget \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*

RUN cd /tmp && git clone --depth 1 ${GEARMAN_REPO}.git
###RUN groupadd gearman \
### && useradd -r -d /var/lib/gearman -g gearman gearman
WORKDIR /tmp/gearmand
RUN ./bootstrap.sh -a
###RUN chown -R gearman:gearman /tmp/gearmand                                                            
###USER gearman                                                                                          

RUN ./configure --enable-ssl 2>&1 | tee ./configure.log
RUN make 2>&1 | tee ./build.log
RUN make test 2>&1 | tee ./test.log

[esabol]

The unittest failure was also reported in issue #200 with gcc 7.3.0, but other unittests besides this one also failed there, I think?

I don't understand why we don't see this in Travis CI.

[esabol]

I don't really get the point of these unittests or why the test is different on macOS and FreeBSD.

If I change the test, like so:

--- /path/to/original/gearmand/libtest/unittest.cc     2019-11-27 17:02:45.553210000 -0500
+++ ./unittest.cc       2019-12-15 01:37:31.932691000 -0500
@@ -663,2 +663 @@
-  ASSERT_EQ(Application::SUCCESS, true_app.run(args));
-  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.join());
+  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.run(args));

It passes on Ubuntu 18.04.

[esabol]

I'm not seeing any error with regards to libpq-fe.h, but the postgres test is being skipped for some reason I haven't yet been able to figure out.

Apparently, the postgres test is skipped unless you set the environment variable POSTGES_IS_RUNNING_AND_SETUP (sic). If I setenv POSTGES_IS_RUNNING_AND_SETUP 1 and then make test-postgres, I get the following output:

postgres.gearmand options.all options                                   0:072053365 [ ok ]
libtest/client.cc:273: in start() pid(1114) localhost:45986 ping(libtest/client.cc:273: Connection refused), additionally pid: 1137 is alive: true waited: 17 server started. exec: /tmp/gearmand/libtool --mode=execute /tmp/gearmand/./gearmand/gearmand --verbose=INFO --log-file=var/log/gearmand.logeQe0wm --pid-file=var/run/gearmand.pidzrqdMX --port=45986 --queue-type=Postgres --libpq-conninfo host=localhost dbname=gearman --libpq-table=gearman -u root --listen=localhost  stderr:/tmp/gearmand/./gearmand/gearmand: Error while initializing the queue : Postgres


./tests/context.h:98: in initialize() pid(1114) Assertion 'server_startup(_servers, "gearmand", _port, argv)'

I think that result is fine, considering PostgreSQL is not actually running?

@SpamapS: Are you sure libpq-dev was installed when you tested?

Also, should I submit a PR to change POSTGES_IS_RUNNING_AND_SETUP to POSTGRES_IS_RUNNING_AND_SETUP?

[esabol]

By the way, a lot of the tests in libtest/unittest.cc refer to /usr/bin/true, but /usr/bin/true doesn't exist on Linux, where it should be using /bin/true instead. These tests end up being skipped on Linux.

We probably need something like

AC_PATH_PROG(TRUE, true, /bin/true, $PATH:/bin:/usr/bin:/sbin:/usr/sbin)
AS_IF([test -z "$TRUE"],
      [AC_MSG_ERROR([could not find true])]])

in configure.ac, but I'm not clear on how to get the value of $ac_cv_prog_TRUE into gear_config.h or something that libtests/unittest.cc can include. Anyone?

Alternatively, could do something like this in libtests/unittest.cc:

#if (defined(__APPLE__) && __APPLE__) || (defined(__FreeBSD__) && __FreeBSD__)
#define TRUE_CMD "/usr/bin/true"
#else
#define TRUE_CMD "/bin/true"
#endif

Thoughts?

[p-alik]

I don't really get the point of these unittests or why the test is different on macOS and FreeBSD.

If I change the test, like so:

--- /path/to/original/gearmand/libtest/unittest.cc     2019-11-27 17:02:45.553210000 -0500
+++ ./unittest.cc       2019-12-15 01:37:31.932691000 -0500
@@ -663,2 +663 @@
-  ASSERT_EQ(Application::SUCCESS, true_app.run(args));
-  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.join());
+  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.run(args));

It passes on Ubuntu 18.04.

I'll confirm the patch solves the issue. Here an other version of the patch.

diff --git a/libtest/unittest.cc b/libtest/unittest.cc
index 30f94d53..beed916f 100644
--- a/libtest/unittest.cc
+++ b/libtest/unittest.cc
@@ -655,14 +655,7 @@ static test_return_t application_doesnotexist_BINARY(void *)
   true_app.will_fail();

   const char *args[]= { "--fubar", 0 };
-#if defined(__APPLE__) && __APPLE__
-  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.run(args));
-#elif defined(__FreeBSD__) && __FreeBSD__
   ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.run(args));
-#else
-  ASSERT_EQ(Application::SUCCESS, true_app.run(args));
-  ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.join());
-#endif

[p-alik]

Alternatively, could do something like this in libtests/unittest.cc:

#if (defined(__APPLE__) && __APPLE__) || (defined(__FreeBSD__) && __FreeBSD__)
#define TRUE_CMD "/usr/bin/true"
#else
#define TRUE_CMD "/bin/true"
#endif

Thoughts?

libtests/unittest.cc-alternative would be my preference.

[esabol]

libtests/unittest.cc-alternative would be my preference.

Please elaborate. Why do you prefer that? How would that work?

[p-alik]

Why do you prefer that?

In my opinion global configuration's amendment for only testing reason should be avoided.

How would that work?

As you proposed with preprocessor directive #define TRUE_CMD ..

[esabol]

Oh, OK, that makes sense. I thought you were proposing something else. 🙂

[SpamapS]

So, where are we at? I'll try the postgres envvar when I get a few minutes, but it seems like the unittest problem needs a PR? Can somebody submit? I may have some time in the holiday, but probably not. Would love to get a release out in January.

[esabol]

So, where are we at? I'll try the postgres envvar when I get a few minutes, but it seems like the unittest problem needs a PR? Can somebody submit?

I would, but it’s not obvious to me what the proper solution is. Various questions remain unanswered. Why does unittest do something different on Linux vs. BSD/Mac? Why did it stop working in Ubuntu 18.04? Will the new/BSD method work on other/older Linux distributions or does it need to be employed only on Ubuntu 18.04? If the latter, how do we do that?

[esabol]

I changed the above Dockerfile to build on Ubuntu 16.04 (Xenial, gcc 5.4.0) and 14.04 (Trusty, gcc 4.8.4):

ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.run(args));

works only on Ubuntu 18.04. It definitely fails on 16.04 and 14.04. On those distributions

ASSERT_EQ(Application::SUCCESS, true_app.run(args));
ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.join());

passes, of course.

How do we handle this? I think the most straightforward solution is to just remove this test. Any other solution seems complicated, and it's not really testing gearmand per se.

[esabol]

How do we handle this? I think the most straightforward solution is to just remove this test. Any other solution seems complicated, and it's not really testing gearmand per se.

Anyone have any feedback on this?

[esabol]

How about this?

  Application::error_t return_value = true_app.run(args);
  if (return_value == Application::INVALID_POSIX_SPAWN)
      ASSERT_EQ(Application::INVALID_POSIX_SPAWN, return_value);
  else
  {   
      ASSERT_EQ(Application::SUCCESS, return_value);
      ASSERT_EQ(Application::INVALID_POSIX_SPAWN, true_app.join());
  }

I've tested this on Ubuntu 14.04, 16.04, and 18.04, and it works on all of them. If nobody has a better idea, I'll submit a PR soon.

[p-alik]

How about this?

LGTM.

[SpamapS]

Nice work everybody. The libpq thing was actually caused or at least made worse by something broken on my build box. Clean Ubuntu 18.04 was able to build properly with the latest master.

Assuming Travis is clean, I'll get a new release out soon!