Unable to use pre-built binaries on alpine linux

[ankurcha]

I am trying to use the netty-tcnative libraries for my grpc application in a docker container. When i use the prebuilt binary I get the following error:

Inconsistency detected by ld.so: dl-lookup.c: 128: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!

[normanmaurer]

we release versions build on centos and debian. I guess you will need to build it by your own for alpine.

[dimitarg]

Assuming an alpine docker image which has an oracle jdk 8 installed, and netty-tcnative available under /opt/data/netty-tcnative (perhaps through a shared volume in the host, if you don't want to bother installing git on the alpine image), here is a setup which let me build netty-tcnative successfully:

MAVEN_VERSION=3.3.3 \
 && cd /usr/share \
 && wget http://archive.apache.org/dist/maven/maven-3/$MAVEN_VERSION/binaries/apache-maven-$MAVEN_VERSION-bin.tar.gz -O - | tar xzf - \
 && mv /usr/share/apache-maven-$MAVEN_VERSION /usr/share/maven \
 && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn


export MAVEN_HOME=/usr/share/maven

cd /opt/data/netty-tcnative/

apk update

apk add autoconf

apk add automake

apk add libtool 

apk add alpine-sdk

apk add apr-util

apk add apr-util-dev

apk add build-base gcc abuild binutils binutils-doc gcc-doc

apk add cmake cmake-doc

apk add ninja

apk add go

, and then

mvn clean install

@ankurcha and anyone else interested, I will let you know if the end result actually works. We use netty directly though, no grpc involved in the test.

[dimitarg]

The built native jar as desribed above, under openssl-dynamic/target/netty-tcnative--linux-x86_64.jar , works for me, if I use the following, in a runtime image based FROM jeanblanchard/java:jdk-8:

run 'apk update'
run 'apk add apr-util apr-util-dev libuuid'

It's very important to change the base image only if you know what you are doing otherwise you might end up not finding libuuid during tcnative load.

Hope this helps. Hopefully I get the time to provide this in a matter more automated than github comments someday.

Cheers, Dimitar

[flozano]

This issue has Fork17 milestone assigned, does it mean it is fixed in Fork17? I can't find the proper alpine linux jar in maven for this version...

Building is a pretty complex process, and it seems alpine is gaining a lot of momentum in docker containers. It would be really great if the binaries were built by default.

[Scottmitch]

this issue has not been resolved ... as of now we don't publish artifacts built from alpine.

[dimitarg]

netty-tcnative-1.1.33.Fork15-linux-x86_64_alpine.jar.zip

Here's the result of the build procedure I described above, for fork15, if you just wanna kick the tires. This is to be used in conjunction with 4.1.0.CR5

I could try automating this via gradle and docker some time after Jun 27. Would netty be interested to host this in a netty github repo, and publish to maven with the netty coordinates?

(It's not required to have the correct coordinates for this to work, NativeLibraryLoader will find it anyways)

[flozano]

Thanks a lot for the effort @dimitarg.

For now I'll have to stick to a more standard glibc-based docker image, but I'm definitely interested in trying to run my components with alpine again when tcnative binaries are part of "official" build/publish process for netty-tcnative.

[pires]

@dimitarg thanks to your work I've automated the build of binaries for Alpine with Docker.
To whomever needs this, feel free to use and abuse.