Hi! I'm trying to update https://hub.docker.com/_/haproxy to the new 2.0.16 release, and the Alpine variant is failing to build (where the previous 2.0.15 release succeeded).
Specifically, the environment we're building in is Alpine 3.12, as seen in https://github.com/docker-library/haproxy/pull/126 (I opened a bump PR for the change so I'd have a nice place to link that will include the build logs and failing CI showing the error).
If you just want to reproduce the failing build locally, the following will "work" (I've included a subset of the failing build logs -- the parts I've ellipsized do not contain any errors or warnings on my builds):
$ docker build https://github.com/docker-library/haproxy.git#a26d2d109d678777805f546220fd38aac6169aeb:2.0/alpine
...
+ make -C /usr/src/haproxy -j 12 all 'TARGET=linux-glibc' 'USE_GETADDRINFO=1' 'USE_LUA=1' 'LUA_INC=/usr/include/lua5.3' 'LUA_LIB=/usr/lib/lua5.3' 'USE_OPENSSL=1' 'USE_PCRE2=1' 'USE_PCRE2_JIT=1' 'USE_ZLIB=1' 'EXTRA_OBJS= contrib/prometheus-exporter/service-prometheus.o '
make: Entering directory '/usr/src/haproxy'
CC src/ev_poll.o
CC src/ev_epoll.o
...
CC contrib/prometheus-exporter/service-prometheus.o
CC ebtree/ebtree.o
CC ebtree/eb32sctree.o
ebtree/ebtree.c: In function 'eb_memcmp':
ebtree/ebtree.c:43:2: error: unknown type name 'ssize_t'; did you mean 'size_t'?
43 | ssize_t ofs = -len;
| ^~~~~~~
| size_t
make: *** [Makefile:845: ebtree/ebtree.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/usr/src/haproxy'
The command '/bin/sh -c set -x && apk add --no-cache --virtual .build-deps gcc libc-dev linux-headers lua5.3-dev make openssl openssl-dev pcre2-dev readline-dev tar zlib-dev && wget -O haproxy.tar.gz "$HAPROXY_URL" && echo "$HAPROXY_SHA256 *haproxy.tar.gz" | sha256sum -c && mkdir -p /usr/src/haproxy && tar -xzf haproxy.tar.gz -C /usr/src/haproxy --strip-components=1 && rm haproxy.tar.gz && makeOpts=' TARGET=linux-glibc USE_GETADDRINFO=1 USE_LUA=1 LUA_INC=/usr/include/lua5.3 LUA_LIB=/usr/lib/lua5.3 USE_OPENSSL=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_ZLIB=1 EXTRA_OBJS=" contrib/prometheus-exporter/service-prometheus.o " ' && nproc="$(getconf _NPROCESSORS_ONLN)" && eval "make -C /usr/src/haproxy -j '$nproc' all $makeOpts" && eval "make -C /usr/src/haproxy install-bin $makeOpts" && mkdir -p /usr/local/etc/haproxy && cp -R /usr/src/haproxy/examples/errorfiles /usr/local/etc/haproxy/errors && rm -rf /usr/src/haproxy && runDeps="$( scanelf --needed --nobanner --format '%n#p' --recursive /usr/local | tr ',' '\n' | sort -u | awk 'system("[ -e /usr/local/lib/" $1 " ]") == 0 { next } { print "so:" $1 }' )" && apk add --no-network --virtual .haproxy-rundeps $runDeps && apk del --no-network .build-deps' returned a non-zero code: 2
I believe the failure was introduced in the 2.0 series via https://github.com/haproxy/haproxy/commit/1b7f58fd2e3f20e2de14a79773d0d7b31f47ffb8, but I'm not sure why that same change doesn't fail to build on the other versions it's already part of (which as far as I can tell is 2.2-dev10+).
I tried setting TARGET=linux-musl like we do on other versions (hoping that would affect the default header inclusions or something), but no dice, presumably because that setting wasn't backported to the 2.0 series? I'm just guessing here -- happy to provide more information or assistance with some guidance!
Good point. On 2.2 we had to add unistd.h to get ssize_t on musl. Does the following change fix the problem for you ? If so it will also be required for 2.1. Thanks!
diff --git a/ebtree/ebtree.c b/ebtree/ebtree.c
index fb266ec..a280acf 100644
--- a/ebtree/ebtree.c
+++ b/ebtree/ebtree.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include <unistd.h>
#include "ebtree.h"
void eb_delete(struct eb_node *node)
Nice, can confirm that patch allows 2.0.16 to build on Alpine 3.12 (and still builds successfully on Debian Buster). :+1:
(Should we apply that patch to our builds in the meantime, or will there be a new 2.0.x that includes it?)
Thanks for testing. Please just apply it to your tree for now, it will be
backported to the next 2.0 but unless there's a big bug there won't be one
in the following days/weeks.
backported to 2.1 and 2.0, closing now.
Most helpful comment
backported to 2.1 and 2.0, closing now.