docker-alpine 🚀 - Alpine libs not compatible with Java 8

This is more of a musl libc issue. The Oracle Java binaries only run on glibc at the moment. We are looking at possibly rebuilding https://aur.archlinux.org/packages/jd/jdk/PKGBUILD and making it available as a standalone package. I'll keep this issue open for now as we have had requests for Java 8 multiple times already.

andyshinn on 27 Feb 2015

Relevant to this is that the java 7 package is slightly broken too- the certstore is broken causing very hard to diagnose errors. The alpine linux irc guys say to copy it in from a debian install

cultureulterior on 10 Mar 2015

(curious) @cultureulterior could you providde more details in your findings plz.

AntonioMeireles on 12 Mar 2015

@AntonioMeireles the java certstore apparently is not regenerated from the CA certs on the machine itself, causing the java ssl to fail to trust certificates that should be trusted

cultureulterior on 13 Mar 2015

I think I may start supporting progrium/busybox again just for Java 8 ... can you guys try that as your base image?

progrium on 13 Mar 2015

+1

pires on 26 Mar 2015

Can anyone point me to relevant information about these musl libc limitations? I have the similar issue with Anaconda prebuilt packages on Alpine Linux:

# ldd /usr/local/miniconda/pkgs/python-2.7.9-1/bin/python
        /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libpython2.7.so.1.0 => /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0 (0x7f9d68a63000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libutil.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __finite: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __rawmemchr: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isinff: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: tmpnam_r: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isnan: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isinf: symbol not found

I do understand that such prebuilt packages are evil, but there is not much I can do in this case except moving to another image for now. :(

However, I would like to understand limits of musl libc better.

frol on 30 Mar 2015

/cc @flaviof @albertocsm

pires on 30 Mar 2015

@cultureulterior not directly related to this issue, but it is possible to manually import all ca certificates to java trusted keystore, as I did it here

denvazh on 31 Mar 2015

We have a new glibc package if anyone would like to test this out. You can grab the package at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk and install with apk add --allow-untrusted glibc-2.21-r2.apk. This should allow Oracle Java 8 and other glibc x86_64 native binaries to run on Alpine.

andyshinn on 9 Apr 2015

👍1

@andyshinn Awesome! It works for me with Miniconda, though I had to bring libz.so from my ubuntu to /usr/lib/libz.so.1 as Alpine Linux has libz.so compiled against musl...

frol on 9 Apr 2015

@andyshinn
UPD: I didn't need to bring libz.so from ubuntu, but needed to create symlinks:
/usr/lib/libc.musl-x86_64.so.1 pointing at /lib/libc.musl-x86_64.so.1
/usr/lib/libz.so.1 pointing at /lib/libz.so.1

Note: For some reason, LD_LIBRARY_PATH doesn't work in this case for me.

frol on 9 Apr 2015

❤1

Are you able to share a Dockerfile or repository with this? I'd like to see how this is working to better support these edge cases.

andyshinn on 9 Apr 2015

@andyshinn Sure!

frol on 9 Apr 2015

@andyshinn

FROM alpine

RUN apk update && \
    apk add bash wget

WORKDIR /tmp

RUN wget --no-check-certificate "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk

RUN wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh"

# This will fail with "ImportError: libz.so.1: cannot open shared object file: No such file or directory"
#RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

# This will succeed
RUN ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1 && \
    ln -s /lib/libz.so.1 /usr/lib/libz.so.1
RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

frol on 9 Apr 2015

I removed the post-install ldconfig but it might actually cover this case. Can you try adding package https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk in addition to the glibc one and then run /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib before installing and see if it works?

andyshinn on 9 Apr 2015

@andyshinn Now it works without symlinking! Great!

Just for the history (it works like a charm):

FROM alpine

RUN apk add --update bash wget ca-certificates

WORKDIR /tmp

RUN wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk && \
    wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-bin-2.21-r2.apk && \
    /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib

# Hotfix for glibc hack that fixes the order of DNS resolving (i.e. check /etc/hosts first and then lookup DNS-servers).
# To fix this we just create /etc/nsswitch.conf and add the following line:
RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf

RUN wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh"

RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

In real world, I suggest you write something like:

FROM alpine

# Here we use several hacks collected from https://github.com/gliderlabs/docker-alpine/issues/11:
# 1. install GLibc (which is not the cleanest solution at all) 
# 2. hotfix /etc/nsswitch.conf, which is apperently required by glibc and is not used in Alpine Linux

RUN apk add --update bash wget ca-certificates && \
    wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" \
         "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk glibc-bin-2.21-r2.apk && \
    /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib && \
    echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf && \
    wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh" && \
    bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda && \
    rm ./Miniconda-latest-Linux-x86_64.sh && \
    apk del bash wget ca-certificates && \
    rm /var/cache/apk/*

This way you avoid packaging unnecessary packages (bash, wget), giant installer (rm miniconda.sh), and outdated apk repository lists.

frol on 9 Apr 2015

A couple of things I want to point out:

Your Python is not part glibc and part musl. Now, I'm a progressive minded person and don't have a problem with this. But Python might... A dual C library stack like this probably isn't all too common so we don't know what the pitfalls are (if any).
When you install pip and then start building more Python extensions (ones requiring build tools such as build-base) those will be linked against musl (be aware of DNS implications this has).
If you are not building additional extensions then we can probably pull in the libz.so from Arch to break the dependency on musl. Soon, i'll have an example of what a package like this looks like

andyshinn on 9 Apr 2015

@andyshinn I don't really use Miniconda it was just a project that I played with. My concern was mostly about the limits of musl libc than about running Miniconda on Alpine Linux. Anyway, thank you for your effort to get things easier in Alpine. I believe, Java people will appreciate this a lot.

frol on 9 Apr 2015

Fair enough, it is something that applies to anyone trying to use glibc on Alpine so just wanted to get it out there. We are definitely more targeting the edge cases of one-off glibc binaries (think Consul) or Java 8 applications that might have all dependencies bundled in a war file already. But it is helpful to see where the limits are, so thank you for that!

andyshinn on 9 Apr 2015

@andyshinn Another example, which may be considered harmful, but nevertheless it made the shortcut possible, is my frolvlad/alpine-mono image, where I use mono package from Arch Linux.

frol on 15 Apr 2015

Here is the Apline OracleJDK 8 image (~~352MB~~ 167MB) - frolvlad/alpine-oraclejkd8

frol on 15 Apr 2015

Thanks! I have successfully build alpine oracle JRE image — size 170MB (old, based on progrium/busybox — 162MB). https://registry.hub.docker.com/u/develar/java/

develar on 21 Apr 2015

hi @andyshinn this works like a charm, please let us know once you have merged it into a released alpine version!

CodingFabian on 28 Apr 2015

Thanks @frol , we're using it now.

ifduyue on 30 Apr 2015

This is fantastic news!

Edit: The solution in https://github.com/boot2docker/boot2docker/issues/451#issuecomment-68874404 works (when using VirtualBox, whether using boot2docker or not).

A slight obstacle is that I'm getting a lot of network issues out of the base "alpine" Docker image, though. APK is intermittently not able to read data. For example:

$ docker run --rm -ti alpine sh
/ # apk -U upgrade
fetch http://dl-4.alpinelinux.org/alpine/v3.1/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-4.alpinelinux.org/alpine/v3.1/main: IO ERROR
WARNING: Ignoring APKINDEX.689bb31a.tar.gz: No such file or directory
OK: 5 MiB in 15 packages
/ # apk -U upgrade
fetch http://dl-4.alpinelinux.org/alpine/v3.1/main/x86_64/APKINDEX.tar.gz
(1/7) Upgrading musl (1.1.5-r2 -> 1.1.5-r4)
(2/7) Upgrading busybox (1.22.1-r14 -> 1.22.1-r15)
ERROR: busybox-1.22.1-r15: Resource temporarily unavailable
(3/7) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
ERROR: alpine-conf-3.1.0-r4: Resource temporarily unavailable
(4/7) Upgrading libcrypto1.0 (1.0.1k-r0 -> 1.0.1m-r1)
ERROR: libcrypto1.0-1.0.1m-r1: Resource temporarily unavailable
(5/7) Upgrading libssl1.0 (1.0.1k-r0 -> 1.0.1m-r1)
(6/7) Upgrading musl-utils (1.1.5-r2 -> 1.1.5-r4)
(7/7) Upgrading alpine-base (3.1.2-r0 -> 3.1.3-r0)
ERROR: alpine-base-3.1.3-r0: Resource temporarily unavailable
4 errors; 5 MiB in 15 packages
/ # apk upgrade
(1/4) Upgrading busybox (1.22.1-r14 -> 1.22.1-r15)
Executing busybox-1.22.1-r15.post-upgrade
(2/4) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
ERROR: alpine-conf-3.1.0-r4: Resource temporarily unavailable
(3/4) Upgrading libcrypto1.0 (1.0.1k-r0 -> 1.0.1m-r1)
(4/4) Upgrading alpine-base (3.1.2-r0 -> 3.1.3-r0)
Executing busybox-1.22.1-r15.trigger
1 errors; 5 MiB in 15 packages
/ # apk upgrade
(1/1) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
Executing busybox-1.22.1-r15.trigger
OK: 5 MiB in 15 packages
/ #

When there are several dependencies (e.g. bash or ca-certificates), some of the dependencies make it, some don't. If I keep trying, though, it eventually works.

When I do eventually get curl, it is also having problems getting data (from a completely different site).

This may be name resolution preferring AAAA records over A records? Here you see ping failing until an IPv4 address is resolved. There is no route to IPv6 networks from the host I'm running on. The ping can subsequently fail if the IPv6 address is resolved again.

$ docker run --rm -ti canva/alpine sh
/ # ping google.com
PING google.com (2404:6800:4006:805::1009): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1008): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1008): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1005): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (74.125.237.160): 56 data bytes
64 bytes from 74.125.237.160: seq=0 ttl=61 time=6.023 ms
64 bytes from 74.125.237.160: seq=1 ttl=61 time=5.549 ms
64 bytes from 74.125.237.160: seq=2 ttl=61 time=6.203 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 5.549/5.925/6.203 ms
/ #

Even supposedly "disabling" IPv6 by updating /etc/sysctl.conf seems to have no affect:

$ docker run --rm -ti canva/alpine sh
/ # cat /etc/sysctl.conf 
net.ipv4.ip_forward = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
kernel.panic = 120
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:11:00:1B  
          inet addr:172.17.0.27  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:1b/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:578 (578.0 B)  TX bytes:578 (578.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

/ # ping google.com
PING google.com (216.58.220.110): 56 data bytes
64 bytes from 216.58.220.110: seq=0 ttl=61 time=3.537 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 3.537/3.537/3.537 ms
/ # ping google.com
PING google.com (2404:6800:4006:801::200e): 56 data bytes
ping: sendto: Network unreachable
/ #

When I do the same activity on @progrium's busybox image with the same busybox version as the Alpine image (1.22.1), no problems are experienced.

delitescere on 30 Apr 2015

@delitescere Try to remove the image and pull it again. I've had the same issue with the base alpine image on one host and it helped.

frol on 30 Apr 2015

@frol sadly, not for me. After removing and pulling again:

$ docker history alpine
IMAGE               CREATED             CREATED BY                                      SIZE
b3dbab3810fc        8 days ago          /bin/sh -c #(nop) ADD file:3cca9bd4719b968870   5.03 MB

FWIW, I think it's a resolver(3) issue with gethostbyname behaving like RES_USE_INET6 has been set by default, when it shouldn't be.

Edit: The solution in https://github.com/boot2docker/boot2docker/issues/451#issuecomment-68874404 works (when using VirtualBox, whether using boot2docker or not).

delitescere on 30 Apr 2015

@delitescere looks like some helpful information here, but can you continue this conversation over on #28 so it doesn't get lost in this discussion about Java.

mgood on 30 Apr 2015

For folks that might come looking, heka also appears to have this glibc requirement (at least as of 0.9.2).

The steps from the above comment did the trick though!

matschaffer on 28 May 2015

@matschaffer do you mean that their binaries require glibc or sources don't compile against musl libc?

Musl libc claims limited binary compatibility with glibc, but I have never seen a project that could work with musl libc without recompilation.

BTW, I've updated my comment (that you linked to) with a recommended way of creating the final image.

frol on 28 May 2015

I believe "their binaries require glibc" - though I'm a little fuzzy on the technicalities.

I haven't actually tried to build it myself so I can't speak to if the sources compile against musl libc or not.

I only used the RUN wget ... && apk ... part which seems to be unchanged since I copied it. That was enough to get the released hekad binary happy.

matschaffer on 28 May 2015

Huh... although I'm noting that once it's running it doesn't seem to resolve against /etc/hosts. Could be a side effect of this.

matschaffer on 28 May 2015

@marcusandre Try my OracleJDK8 fix:

# Alpine Linux doesn't use pam, which means that there is no /etc/nsswitch.conf,
# but Java relies on /etc/nsswitch.conf to check the order of DNS resolving
# (i.e. check /etc/hosts first and then lookup DNS-servers).
# To fix this we just create /etc/nsswitch.conf and add the following line:
RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf

frol on 28 May 2015

Looking at this, it seems that it wasn't a Java bug, but glibc hack side effect...

@andyshinn You know better about glibc packages. Do you think it is possible that this nsswitch.conf issue is introduced because of them?

frol on 28 May 2015

👍1

@frol hey thanks adding that nsswitch line did indeed get hosts resolution working again. So now with a pair of ssh tunnels I can end-to-end test from boot2docker against Amazon's email service :+1:

matschaffer on 28 May 2015

Where does JDK/JRE8 support stand? I see here some folks that managed to get libc + some hacks working. Is that the official way, or is more official support for glibc in the works?

gzoller on 27 Oct 2015

Working great for me. See https://hub.docker.com/r/delitescere/jvm-prep/

delitescere on 27 Oct 2015

@delitescere well you write in your own Dockerfile that this is a temporary workaround. so the question is: is it in fact a temporary workaround, and when will it be fixed in apline base image.

CodingFabian on 27 Oct 2015

Well, I think the goal would be to simplify the installation of glibc, but I don't think it would be installed in the base image. It would definitely be nice to simply apk add glibc but installing it by default would increase the size of the image, and might cause confusion or issues in cases where it wasn't actually required.

mgood on 3 Nov 2015

@mgood agreed. It should not be in the base image, @CodingFabian, but it could be easier to install.

delitescere on 3 Nov 2015

In the first place, the issue of OracleJDK not working on Alpine is not the issue of Alpine, but the issue of OracleJDK, which is not compiled for musl libc. Thus, if you wish to get things fixed properly, you have to ask Oracle to support musl libc. Meanwhile, everything that we implement here would be a hack either you install glibc from a repository or wget + apk add <files>. Nevertheless, there are two images that should save almost everybody from headaches: frolvlad/alpine-oraclejdk8 (167MB Oracle JDK image) and develar/java (117MB Oracle JRE image). I try to keep my image up-to-date, and I use it in production in my current projects.

frol on 4 Nov 2015

👍1

Mine, using Zulu OpenJDK, are 162MB (JDK https://hub.docker.com/r/delitescere/jdk/) and 86MB (JRE https://hub.docker.com/r/delitescere/java/) respectively.

delitescere on 4 Nov 2015

Technically I understand this thought but it's not realistic to expect a huge company like oracle to support every lib combo out there especially one that isn't the "top" one in terms of raw adoption. (I do get the appeal of musl)

If you want to be able to support a major constituency like oraclejdk users the smaller ship not the larger needs to turn.

My thought on the matter is that busybox had this support and Alpine is positioning itself as the successor to busybox then conceptually there shouldn't be a major loss of capability.

Sent from my iPhone

On Nov 3, 2015, at 11:11 PM, Vlad Frolov [email protected] wrote:

In the first place, the issue of OracleJDK not working on Alpine is not the issue of Alpine, but the issue of OracleJDK, which is not compiled for musl libc. Thus, if you wish to get things fixed properly, you have to ask Oracle to support musl libc. Meanwhile, everything that we implement here would be a hack either you install glibc from a repository or wget + apk add . Nevertheless, there are two images that should save almost everybody from headaches: frolvlad/alpine-oraclejdk8 (167MB Oracle JDK image) and develar/java (117MB Oracle JRE image). I try to keep my image up-to-date, and I use it in production in my current projects.

—
Reply to this email directly or view it on GitHub.

gzoller on 4 Nov 2015

You may want to take a look at one of our production alpine/JDK8 install scripts for our alpinejava docker image:
https://github.com/garywiz/chaperone-docker/blob/master/alpinejava/setup/install.sh

We put this together quite a while ago, and it incorporates many of the suggestions in this thread as well as other threads (including the circle-artifacts glibc, nsswitch patch, etc). We have about 10 clients using production derivatives from this and it might serve as a template, who knows.

garywiz on 4 Nov 2015

Cool. I'll check it out.

Sent from my iPhone

On Nov 4, 2015, at 5:08 PM, Gary Wisniewski [email protected] wrote:

You may want to take a look at one of our production alpine/JDK8 install scripts for our alpinejava docker image:
https://github.com/garywiz/chaperone-docker/blob/master/alpinejava/setup/install.sh

We put this together quite a while ago, and it incorporates many of the suggestions in this thread as well as other threads (including the circle-artifacts glibc, nsswitch patch, etc). We have about 10 clients using production derivatives from this and it might serve as a template, who knows.

—
Reply to this email directly or view it on GitHub.

gzoller on 5 Nov 2015

@gzoller Use frolvlad/alpine-glibc and you will feel it just like busybox.

@garywiz It is just the same as my frolvlad/alpine-oraclejdk8 image. 3.9k pulls of my image and two of my production projects shows that the image is stable.

frol on 5 Nov 2015

@frol Thanks you! Very excited it runs go scripts too, which my attempt to run a Alpine/glibc mashup did not. This is going to be a nice base for me.

gzoller on 6 Nov 2015

@andyshinn

I read your comments on Apr 10, and I think I have the issue you mentioned.

Since python extensions are not built with glibc, I can't make tensorflow (https://github.com/tensorflow/tensorflow) work in alpine.

The issue i raised : https://github.com/tensorflow/tensorflow/issues/103

any suggestions?

ozbillwang on 11 Nov 2015

Yes, actually! Check out frolvlad/alpine-glibc

This worked great for me.

On Nov 11, 2015, at 7:18 AM, Bill W [email protected] wrote:

@andyshinn

I read your comments on Apr 10, and I think I met the issue you mentioned.

Since python extensions is not built with glibc, I can't make tensorflow (https://github.com/tensorflow/tensorflow) work in alpine.

The issue i raised : tensorflow/tensorflow#103

any suggestions?

—
Reply to this email directly or view it on GitHub.

gzoller on 11 Nov 2015

Check out frolvlad/alpine-glibc

links: https://github.com/search?utf8=%E2%9C%93&q=alpine-glibc

jumanjiman on 11 Nov 2015

@SydOps You may use Python compiled for glibc, for example Miniconda, something along the lines (not tested):

FROM frolvlad/alpine-glibc

RUN apk add --update bash wget ca-certificates && \
    wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh" && \
    bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda && \
    rm ./Miniconda-latest-Linux-x86_64.sh && \
    ln -s ../miniconda/bin/* /usr/local/bin/ && \
    apk del bash wget && \
    rm /var/cache/apk/*

frol on 11 Nov 2015

Thanks @frol , your Dockerfile works fine, I add below lines in it base on your image.

FROM python-alpine-glibc

RUN /usr/glibc/usr/bin/ldconfig /lib /usr/local/miniconda/lib
ENV PATH /usr/local/miniconda/bin:$PATH
RUN conda install -y numpy

RUN pip install https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.5.0-cp27-none-linux_x86_64.whl

CMD ["/bin/sh"]

now I saw different error:

docker@default:~/Docker-builder/tensorflow/alpine$ docker run -ti tensorflow sh
/ # python
Python 2.7.10 |Continuum Analytics, Inc.| (default, Oct 19 2015, 18:04:42)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import tensorflow
Traceback (most recent call last):
...
    _pywrap_tensorflow = swig_import_helper()
  File "/usr/local/miniconda/lib/python2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 24, in swig_import_helper
    _mod = imp.load_module('_pywrap_tensorflow', fp, pathname, description)
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory
>>>

check the package libstdc++ which need musl again.

ozbillwang on 11 Nov 2015

@SydOps Try adding conda install libgcc.

frol on 12 Nov 2015

Thanks, @frol

I understand now, after Miniconda is enabled, all lib updates should be installed through conda.

Will try and update the result later.

ozbillwang on 12 Nov 2015

@frol

Yes, the problem is fixed, thanks a lot

ozbillwang on 12 Nov 2015

I pushed a new glibc package builder. The artifact is at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/glibc-2.22-r5.apk. If someone could help test it out that would be great. This one is the first step in using my own built glibc binary from https://github.com/andyshinn/docker-glibc-builder.

andyshinn on 27 Nov 2015

@andyshinn I have tried out your new artifacts with Miniconda (as there is already an example above with the old artifacts). Unfortunately, it didn't go smoothly. Here is my Dockerfile:

FROM alpine

RUN apk add --update bash wget ca-certificates && \
    wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/glibc-2.22-r5.apk" \
         "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/glibc-bin-2.22-r5.apk" && \
    apk add --allow-untrusted glibc-2.22-r5.apk glibc-bin-2.22-r5.apk && \
    /usr/glibc-compat/sbin/ldconfig /lib /usr/glibc-compat/lib && \
    wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh" #&& \

And here is my session:

$ docker run -it --rm qq sh
/ # bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda
PREFIX=/usr/local/miniconda
installing: python-2.7.10-2 ...
installing: conda-env-2.4.4-py27_0 ...
installing: openssl-1.0.2d-0 ...
installing: pycosat-0.6.1-py27_0 ...
installing: pyyaml-3.11-py27_1 ...
installing: readline-6.2-2 ...
installing: requests-2.8.1-py27_0 ...
installing: sqlite-3.8.4.1-1 ...
installing: tk-8.5.18-0 ...
installing: yaml-0.1.6-0 ...
installing: zlib-1.2.8-0 ...
installing: conda-3.18.3-py27_0 ...
installing: pycrypto-2.6.1-py27_0 ...
installing: _cache-0.0-py27_x0 ...
./Miniconda-latest-Linux-x86_64.sh: line 287: /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python: No such file or directory
ERROR:
cannot execute native linux-64 binary, output from 'uname -a' is:
Linux 5c561b7d85f6 4.3.0-2-lqx #1 ZEN SMP PREEMPT Thu Nov 19 10:06:38 ICT 2015 x86_64 Linux

/ # /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python
sh: /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python: not found

/ # /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python
Python 2.7.10 |Continuum Analytics, Inc.| (default, Oct 19 2015, 18:04:42)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>>

As you can see, I can run the Python executable if I explicitly use /usr/glibc-compat/lib/ld-linux-x86-64.so.2, but I cannot just run the executable as I could do with the old artifacts. Do you have any ideas?

BTW, ldconfig complains about missing /usr/glibc-compat/etc/ld.so.conf, which could be included into the packages.

frol on 27 Nov 2015

Same thing as above with phantomjs:

# phantomjs 
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/lib/libstdc++.so.6)
Error relocating /usr/lib/libstdc++.so.6: __memcpy_chk: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __cxa_thread_atexit_impl: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __sprintf_chk: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __snprintf_chk: symbol not found
Error relocating /usr/bin/node: _ZSt24__throw_out_of_range_fmtPKcz: symbol not found

I found that the /lib64/ directory was missing from the last build @andyshinn @frol, the same directory which contains ld-linux-x86-64.so.2 -> /usr/glibc/usr/lib/ld-linux-x86-64.so.2 in v2.21-r2.

You can restore the previous behavior by adding these lines to your Dockerfile:

RUN [...]
  && mkdir /lib64 \
  && ln -s /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /lib64

antoineco on 27 Nov 2015

I'll use https://hub.docker.com/r/frolvlad/alpine-oraclejdk8/~/dockerfile/ as a test for new packages. But @antoineco what is a PahntomJS image that is currently working that I can test with? I can't get PhantomJS to work with the new or old one.

andyshinn on 29 Nov 2015

Me neither actually, on Alpine + glibc it throws bin/phantomjs: /usr/lib/libstdc++.so.6: no version information available, and when I replace libstdc++.so.6 by the Ubuntu version I get a segmentation fault. Eventually I got it working on Alpine by using dockerize on the PhantomJS binary and pushing all the resulting libraries to my image (which includes glibc).

Long story short, PhantomJS only works with GNU libraries.

In case you're curious, here is the full list of libraries I pushed from Ubuntu 14.04 to Alpine in order to make it work:

lib/x86_64-linux-gnu/
lib/x86_64-linux-gnu/libdl.so.2
lib/x86_64-linux-gnu/libc.so.6
lib/x86_64-linux-gnu/libnss_files.so.2
lib/x86_64-linux-gnu/libz.so.1
lib/x86_64-linux-gnu/libpthread.so.0
lib/x86_64-linux-gnu/librt.so.1
lib/x86_64-linux-gnu/libm.so.6
lib/x86_64-linux-gnu/libpng12.so.0
lib/x86_64-linux-gnu/libgcc_s.so.1
lib/x86_64-linux-gnu/libnss_compat.so.2
lib/x86_64-linux-gnu/libexpat.so.1
lib/x86_64-linux-gnu/libnss_dns.so.2
lib64/ld-linux-x86-64.so.2
usr/lib/x86_64-linux-gnu/libfontconfig.so.1
usr/lib/x86_64-linux-gnu/libstdc++.so.6
usr/lib/x86_64-linux-gnu/libfreetype.so.6

antoineco on 29 Nov 2015

Yea, I already did a lot of work to try and build PhantomJS linked against Alpine libs. Fabio Rehm did some work on this also and has a good article about it and his image at http://fabiorehm.com/blog/2015/07/22/building-a-minimum-viable-phantomjs-2-docker-image/. Unfortunately, PhantomJS has an extremely involved compilation process that will likely require lots of hacking to compile properly on musl.

Though, a builder image, with dockerize + PhantomJS to produce an Alpine package like I am doing for glibc might be a 3rd option to explore.

andyshinn on 29 Nov 2015

Hi, I believe the issue I have might be related to the discussion here.

One of the npm modules I am trying to use uses does not work in Alpine using @frol 's frol/docker-alpine-glibc image.
At first, it failed while loading the shared library: libcrypt.so.1.
I got around that by running export LD_LIBRARY_PATH=/usr/glibc/usr/lib.
Now, I am getting the following error messages when I run ldd on the lib file from the module that causes an error:

    ldd (0x7fc87561a000)
    libcrypt.so.1 => /usr/glibc/usr/lib/libcrypt.so.1 (0x7fc8731ea000)
    libdl.so.2 => ldd (0x7fc87561a000)
    libpthread.so.0 => ldd (0x7fc87561a000)
    librt.so.1 => ldd (0x7fc87561a000)
    libpam.so.0 => /lib/libpam.so.0 (0x7fc872fdd000)
    libxml2.so.2 => /usr/lib/libxml2.so.2 (0x7fc872cb2000)
    libm.so.6 => ldd (0x7fc87561a000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fc8729bf000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fc8727ad000)
    libc.so.6 => ldd (0x7fc87561a000)
    libz.so.1 => /lib/libz.so.1 (0x7fc872597000)
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __open: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __read: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __libc_alloca_cutoff: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: errno: symbol not found

Any comments or thoughts would be greatly appreciated.

hwangbible on 3 Dec 2015

@hwangbible I guess, you are trying to mix node.js from Alpine official repos, thus node.js is linked to musl libc, and an npm module that is proprietary or just has a precompiled library (which is apparently linked against glibc). This might be an unsolvable case as it is, so I suggest you either (1) recompile the npm module from sources, so the library is linked against musl libc, or (2) use node.js linked against glibc (for example, download Arch Linux packages, like I did for frolvlad/alpine-mono).

P.S. ldd that you are using is working with musl libc (and the /usr/glibc/usr/bin/ldd is simply broken), so to check libraries on a glibc binary you need to run the following command:

$ LD_TRACE_LOADED_OBJECTS=1 /usr/glibc/usr/lib/ld-linux-x86-64.so.2  "path_to_your_binary"

frol on 3 Dec 2015

@frol Thank you very much for the prompt response!
I was actually recompiling node v0.12.7 sources downloaded from nodejs.org. That module with the precompiled library installed fine via npm. Is that not enough? Would I have to recompile npm in addition to recompiling nodejs?

hwangbible on 4 Dec 2015

@hwangbible If you have rebuilt node on Alpine, then nodejs is linked against musl libc and it is just the same situation as I have already described. npm is just a package manager, it delivers files to your system, but you need to make sure that those files are compatible. Recompile that prebuilt library or use NodeJS linked against glibc.

frol on 4 Dec 2015

@frol I downloaded nodejs package from Arch Linux packages and untar'd it on to frolvlad:alpine-glibc:3.2. It warns with the following message: /usr/lib/libstdc++.so.6: no version information available (required by node) and doesn't include npm. Any idea how to get rid of the warning?

hwangbible on 7 Dec 2015

@hwangbible Get libstdc++.so.6 from Arch Linux also (it is in gcc-libs package) and put it into /usr/glibc/usr/lib/ folder, and run ldconfig. Actually, as I have already warned, Alpine's packages become almost completely useless once you start using glibc since you must use glibc-targeted libraries everywhere. Still sometimes it makes some sense (i.e. when you use Java, or completely self-bundled packages like Anaconda (Python)). In your case, I think it is too troublesome.

frol on 8 Dec 2015

@frol Thank you very much for all your responses! I will probably have to look for an alternative for now.

hwangbible on 8 Dec 2015

@andyshinn It would be nice to have a glibc-dev package with headers.

sdurrheimer on 9 Dec 2015

@andyshinn Downloaded golang binaries works on your glibc-2.21-r2.apk but not on glibc-2.22-r5.apk

sdurrheimer on 10 Dec 2015

@sdurrheimer see https://github.com/gliderlabs/docker-alpine/issues/11#issuecomment-160202945

antoineco on 10 Dec 2015

@antoineco Indeed the missing /lib64/lib/ld-linux-x86-64.so.2. Kind of strange because it is in fact in the apk package building procedure : https://github.com/andyshinn/alpine-pkg-glibc/blob/master/APKBUILD#L27

sdurrheimer on 10 Dec 2015

But it was restored after the package was built :)
https://github.com/andyshinn/alpine-pkg-glibc/commit/f972199cf1aa781d2b862a641b7755768a6f567c

antoineco on 10 Dec 2015

Yep just saw that. Need to use
https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/13/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/
instead of
https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/

sdurrheimer on 10 Dec 2015

Just to add my $0.02 here: I'm trying to make Alpine work as a minimal OpenStack image to run Go and Java services. I'm not looking for a docker solution since I want to run the apps directly. Therefore apk add glibc would be a welcome addition.

magiconair on 2 Jan 2016

@magiconair I don't think glibc package will ever make to the official repo since it is a pure hack. Making a repo for glibc package is doable and, in fact, you can make the repo yourself, but at this point of time there is only one set of artifacts (2.21-r2) which works and others just don't. However, I also support the idea of having a repo for glibc in future, so it can be installed in a standard way.

frol on 3 Jan 2016

I've been holding my breath since I started using Alpine as a base image, but the glibc hackery finally blew up for me today in a CI job:

01:49:46 *** Error in `java': free(): invalid size: 0x00000001009c8d50 ***
01:49:46 ======= Backtrace: =========
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x7198e)[0x7f9134e5898e]
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x76dee)[0x7f9134e5ddee]
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x775cb)[0x7f9134e5e5cb]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x622b41)[0x7f9134440b41]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x9a516c)[0x7f91347c316c]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x9a5e66)[0x7f91347c3e66]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0xab446f)[0x7f91348d246f]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0xab48f0)[0x7f91348d28f0]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x911048)[0x7f913472f048]
01:49:46 /usr/glibc/usr/lib/libpthread.so.0(+0x7374)[0x7f91355ab374]
01:49:46 /usr/glibc/usr/lib/libc.so.6(clone+0x6d)[0x7f9134ecf27d]
01:49:46 ======= Memory map: ========
01:49:46 00400000-00401000 r-xp 00000000 fd:04 1312104                            /usr/lib/jvm/java-8-oracle/bin/java
01:49:46 00600000-00601000 rw-p 00000000 fd:04 1312104                            /usr/lib/jvm/java-8-oracle/bin/java
01:49:46 01230000-01251000 rw-p 00000000 00:00 0                                  [heap]
01:49:46 c0000000-10104a000 rw-p 00000000 00:00 0 
01:49:46 10104a000-140000000 ---p 00000000 00:00 0 
01:49:46 7f909c000000-7f909c021000 rw-p 00000000 00:00 0 
01:49:46 7f909c021000-7f90a0000000 ---p 00000000 00:00 0 
01:49:46 7f90a4000000-7f90a407b000 rw-p 00000000 00:00 0 
01:49:46 7f90a407b000-7f90a8000000 ---p 00000000 00:00 0 
01:49:46 7f90a8000000-7f90a8021000 rw-p 00000000 00:00 0 
01:49:46 7f90a8021000-7f90ac000000 ---p 00000000 00:00 0 
01:49:46 7f90ac000000-7f90ac021000 rw-p 00000000 00:00 0 
01:49:46 7f90ac021000-7f90b0000000 ---p 00000000 00:00 0 
01:49:46 7f90b0000000-7f90b0021000 rw-p 00000000 00:00 0 
01:49:46 7f90b0021000-7f90b4000000 ---p 00000000 00:00 0 
01:49:46 7f90b4000000-7f90b4021000 rw-p 00000000 00:00 0 
01:49:46 7f90b4021000-7f90b8000000 ---p 00000000 00:00 0 
01:49:46 7f90b8000000-7f90b8021000 rw-p 00000000 00:00 0 
01:49:46 7f90b8021000-7f90bc000000 ---p 00000000 00:00 0 
01:49:46 7f90bce36000-7f90bcebe000 r-xp 00000000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bcebe000-7f90bd0bd000 ---p 00088000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0bd000-7f90bd0be000 r--p 00087000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0be000-7f90bd0bf000 rw-p 00088000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0bf000-7f90bd0c2000 rw-p 00000000 00:00 0 
01:49:46 7f90bd0c2000-7f90bd0d3000 r-xp 00000000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd0d3000-7f90bd2d2000 ---p 00011000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d2000-7f90bd2d3000 r--p 00010000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d3000-7f90bd2d4000 rw-p 00011000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d4000-7f90bd2d7000 ---p 00000000 00:00 0 
01:49:46 7f90bd2d7000-7f90bd3d5000 rw-p 00000000 00:00 0                          [stack:130]
01:49:46 7f90bd3d5000-7f90bd3d8000 ---p 00000000 00:00 0 
01:49:46 7f90bd3d8000-7f90bd4d6000 rw-p 00000000 00:00 0                          [stack:129]
01:49:46 7f90bd4d6000-7f90bd4d9000 ---p 00000000 00:00 0 
01:49:46 7f90bd4d9000-7f90bd5d7000 rw-p 00000000 00:00 0                          [stack:128]
01:49:46 7f90bd5d7000-7f90bd5da000 ---p 00000000 00:00 0 
01:49:46 7f90bd5da000-7f90bd6d8000 rw-p 00000000 00:00 0                          [stack:127]
01:49:46 7f90bd6d8000-7f90bd6db000 ---p 00000000 00:00 0 
01:49:46 7f90bd6db000-7f90bd7d9000 rw-p 00000000 00:00 0                          [stack:126]
01:49:46 7f90bd7d9000-7f90bd7dc000 ---p 00000000 00:00 0 
01:49:46 7f90bd7dc000-7f90bd8da000 rw-p 00000000 00:00 0                          [stack:125]
01:49:46 7f90bd8da000-7f90bd8dd000 ---p 00000000 00:00 0 
01:49:46 7f90bd8dd000-7f90bd9db000 rw-p 00000000 00:00 0                          [stack:124]
01:49:46 7f90bd9db000-7f90bd9de000 ---p 00000000 00:00 0 
01:49:46 7f90bd9de000-7f90bdadc000 rw-p 00000000 00:00 0                          [stack:123]
01:49:46 7f90bdadc000-7f90bdadf000 ---p 00000000 00:00 0 
01:49:46 7f90bdadf000-7f90bdbdd000 rw-p 00000000 00:00 0                          [stack:122]
01:49:46 7f90bdbdd000-7f90bdbe0000 ---p 00000000 00:00 0 
01:49:46 7f90bdbe0000-7f90bdcde000 rw-p 00000000 00:00 0                          [stack:121]
01:49:46 7f90bdcde000-7f90bdce1000 ---p 00000000 00:00 0 
01:49:46 7f90bdce1000-7f90bdddf000 rw-p 00000000 00:00 0                          [stack:120]
01:49:46 7f90bdddf000-7f90bdde2000 ---p 00000000 00:00 0 
01:49:46 7f90bdde2000-7f90be044000 rw-p 00000000 00:00 0                          [stack:119]
01:49:46 7f90be044000-7f90be0e0000 ---p 00000000 00:00 0 
01:49:46 7f90be0e0000-7f90be0e3000 ---p 00000000 00:00 0 
01:49:46 7f90be0e3000-7f90be1e1000 rw-p 00000000 00:00 0                          [stack:118]
01:49:46 7f90be1e1000-7f90be1e4000 ---p 00000000 00:00 0 
01:49:46 7f90be1e4000-7f90be2e2000 rw-p 00000000 00:00 0                          [stack:117]
01:49:46 7f90be2e2000-7f90be2e5000 ---p 00000000 00:00 0 
01:49:46 7f90be2e5000-7f90be3e3000 rw-p 00000000 00:00 0                          [stack:116]
01:49:46 7f90be3e3000-7f90be3e6000 ---p 00000000 00:00 0 
01:49:46 7f90be3e6000-7f90be4e4000 rw-p 00000000 00:00 0                          [stack:115]
01:49:46 7f90be4e4000-7f90be4e7000 ---p 00000000 00:00 0 
01:49:46 7f90be4e7000-7f90be5e5000 rw-p 00000000 00:00 0                          [stack:114]
01:49:46 7f90be5e5000-7f90be5ed000 r-xp 00000000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be5ed000-7f90be7ed000 ---p 00008000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be7ed000-7f90be7ee000 rw-p 00008000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be7ee000-7f90be9ee000 rw-p 00000000 00:00 0 
01:49:46 7f90be9ee000-7f90be9f1000 ---p 00000000 00:00 0 
01:49:46 7f90be9f1000-7f90becef000 rw-p 00000000 00:00 0                          [stack:113]
01:49:46 7f90becef000-7f90becf2000 ---p 00000000 00:00 0 
01:49:46 7f90becf2000-7f90bedf0000 rw-p 00000000 00:00 0                          [stack:111]
01:49:46 7f90bedf0000-7f90bedf3000 ---p 00000000 00:00 0 
01:49:46 7f90bedf3000-7f90beef1000 rw-p 00000000 00:00 0                          [stack:110]
01:49:46 7f90beef1000-7f90beef4000 ---p 00000000 00:00 0 
01:49:46 7f90beef4000-7f90beff2000 rw-p 00000000 00:00 0                          [stack:109]
01:49:46 7f90beff2000-7f90beff5000 ---p 00000000 00:00 0 
01:49:46 7f90beff5000-7f90bf0f3000 rw-p 00000000 00:00 0                          [stack:108]
01:49:46 7f90bf0f3000-7f90bf0f6000 ---p 00000000 00:00 0 
01:49:46 7f90bf0f6000-7f90bf1f4000 rw-p 00000000 00:00 0                          [stack:107]
01:49:46 7f90bf1f4000-7f90bf1f7000 ---p 00000000 00:00 0 
01:49:46 7f90bf1f7000-7f90bf4f5000 rw-p 00000000 00:00 0                          [stack:106]
01:49:46 7f90bf4f5000-7f90bf4f8000 ---p 00000000 00:00 0 
01:49:46 7f90bf4f8000-7f90bf5f6000 rw-p 00000000 00:00 0                          [stack:105]
01:49:46 7f90bf5f6000-7f90bf5f9000 ---p 00000000 00:00 0 
01:49:46 7f90bf5f9000-7f90bf6f7000 rw-p 00000000 00:00 0                          [stack:104]
01:49:46 7f90bf6f7000-7f90bf6fa000 ---p 00000000 00:00 0 
01:49:46 7f90bf6fa000-7f90bf7f8000 rw-p 00000000 00:00 0                          [stack:103]
01:49:46 7f90bf7f8000-7f90bf7fb000 ---p 00000000 00:00 0 
01:49:46 7f90bf7fb000-7f90bf8f9000 rw-p 00000000 00:00 0                          [stack:102]
01:49:46 7f90bf8f9000-7f90bf8fc000 ---p 00000000 00:00 0 
01:49:46 7f90bf8fc000-7f90bf9fa000 rw-p 00000000 00:00 0                          [stack:101]
01:49:46 7f90bf9fa000-7f90bf9fd000 ---p 00000000 00:00 0 
01:49:46 7f90bf9fd000-7f90bfafb000 rw-p 00000000 00:00 0                          [stack:100]
01:49:46 7f90bfafb000-7f90bfafe000 ---p 00000000 00:00 0 
01:49:46 7f90bfafe000-7f90bfbfc000 rw-p 00000000 00:00 0                          [stack:99]
01:49:46 7f90bfbfc000-7f90bfbff000 ---p 00000000 00:00 0 
01:49:46 7f90bfbff000-7f90bfcfd000 rw-p 00000000 00:00 0                          [stack:98]
01:49:46 7f90bfcfd000-7f90bfd00000 ---p 00000000 00:00 0 
01:49:46 7f90bfd00000-7f90bfdfe000 rw-p 00000000 00:00 0                          [stack:97]
01:49:46 7f90bfdfe000-7f90bfe01000 ---p 00000000 00:00 0 
01:49:46 7f90bfe01000-7f90bfeff000 rw-p 00000000 00:00 0                          [stack:96]
01:49:46 7f90bfeff000-7f90bff02000 ---p 00000000 00:00 0 
01:49:46 7f90bff02000-7f90c0000000 rw-p 00000000 00:00 0                          [stack:95]
01:49:46 7f90c0000000-7f90c028b000 rw-p 00000000 00:00 0 
01:49:46 7f90c028b000-7f90c4000000 ---p 00000000 00:00 0 
01:49:46 7f90c4000000-7f90c4021000 rw-p 00000000 00:00 0 
01:49:46 7f90c4021000-7f90c8000000 ---p 00000000 00:00 0 
01:49:46 7f90c8000000-7f90c87ca000 rw-p 00000000 00:00 0 
01:49:46 7f90c87ca000-7f90cc000000 ---p 00000000 00:00 0 
01:49:46 7f90cc000000-7f90cc307000 rw-p 00000000 00:00 0 
01:49:46 7f90cc307000-7f90d0000000 ---p 00000000 00:00 0 
01:49:46 7f90d0000000-7f90d010a000 rw-p 00000000 00:00 0 
01:49:46 7f90d010a000-7f90d4000000 ---p 00000000 00:00 0 
01:49:46 7f90d4000000-7f90d4021000 rw-p 00000000 00:00 0 
01:49:46 7f90d4021000-7f90d8000000 ---p 00000000 00:00 0 
01:49:46 7f90d8000000-7f90d803a000 rw-p 00000000 00:00 0 
01:49:46 7f90d803a000-7f90dc000000 ---p 00000000 00:00 0 
01:49:46 7f90dc000000-7f90dc244000 rw-p 00000000 00:00 0 
01:49:46 7f90dc244000-7f90e0000000 ---p 00000000 00:00 0 
01:49:46 7f90e0000000-7f90e0bbb000 rw-p 00000000 00:00 0 
01:49:46 7f90e0bbb000-7f90e4000000 ---p 00000000 00:00 0 
01:49:46 7f90e4000000-7f90e4021000 rw-p 00000000 00:00 0 
01:49:46 7f90e4021000-7f90e8000000 ---p 00000000 00:00 0 
01:49:46 7f90e8072000-7f90e8272000 rw-p 00000000 00:00 0 
01:49:46 7f90e8272000-7f90e8275000 ---p 00000000 00:00 0 
01:49:46 7f90e8275000-7f90e8373000 rw-p 00000000 00:00 0                          [stack:94]
01:49:46 7f90e8373000-7f90e8376000 ---p 00000000 00:00 0 
01:49:46 7f90e8376000-7f90e8474000 rw-p 00000000 00:00 0                          [stack:93]
01:49:46 7f90e8474000-7f90e8477000 ---p 00000000 00:00 0 
01:49:46 7f90e8477000-7f90e8775000 rw-p 00000000 00:00 0                          [stack:92]
01:49:46 7f90e8775000-7f90e8975000 rw-p 00000000 00:00 0 
01:49:46 7f90e8975000-7f90e8b75000 rw-p 00000000 00:00 0 
01:49:46 7f90e8b75000-7f90e8d75000 rw-p 00000000 00:00 0 
01:49:46 7f90e8d75000-7f90e8f75000 rw-p 00000000 00:00 0 
01:49:46 7f90e8f75000-7f90e9175000 rw-p 00000000 00:00 0 
01:49:46 7f90e9175000-7f90e9375000 rw-p 00000000 00:00 0 
01:49:46 7f90e9375000-7f90e9575000 rw-p 00000000 00:00 0 
01:49:46 7f90e9575000-7f90e9775000 rw-p 00000000 00:00 0 
01:49:46 7f90e9775000-7f90e9975000 rw-p 00000000 00:00 0 
01:49:46 7f90e9975000-7f90e9b75000 rw-p 00000000 00:00 0 
01:49:46 7f90e9b75000-7f90e9d75000 rw-p 00000000 00:00 0 
01:49:46 7f90e9d75000-7f90e9f71000 rw-p 00000000 00:00 0 
01:49:46 7f90e9f71000-7f90e9f75000 ---p 00000000 00:00 0 
01:49:46 7f90e9f75000-7f90e9f83000 r--s 00191000 fd:04 1441826                    /root/.ivy2/cache/com.h2database/h2/jars/h2-1.4.187.jar
01:49:46 7f90e9f83000-7f90e9fe9000 r--s 00669000 fd:04 1442276                    /root/.ivy2/cache/org.scalatest/scalatest_2.11/bundles/scalatest_2.11-2.2.0.jar
01:49:46 7f90e9fe9000-7f90e9fee000 r--s 00039000 fd:04 1441919                    /root/.ivy2/cache/com.typesafe.akka/akka-testkit_2.11/jars/akka-testkit_2.11-2.3.11.jar
01:49:46 7f90e9fee000-7f90e9ff1000 r--s 00010000 fd:04 1442021                    /root/.ivy2/cache/io.spray/spray-testkit_2.11/jars/spray-testkit_2.11-1.3.3.jar
01:49:46 7f90e9ff1000-7f90e9ff3000 r--s 00005000 fd:04 1442251                    /root/.ivy2/cache/org.objenesis/objenesis/jars/objenesis-1.0.jar
01:49:46 7f90e9ff3000-7f90e9ff5000 r--s 00011000 fd:04 1442197                    /root/.ivy2/cache/org.hamcrest/hamcrest-core/jars/hamcrest-core-1.1.jar
01:49:46 7f90e9ff5000-7f90ea014000 r--s 00150000 fd:04 1442244                    /root/.ivy2/cache/org.mockito/mockito-core/jars/mockito-core-1.9.5.jar
01:49:46 7f90ea014000-7f90ea01f000 r--s 0008b000 fd:04 1315921                    /root/.ivy2/cache/c3p0/c3p0/jars/c3p0-0.9.1.2.jar
01:49:46 7f90ea01f000-7f90ea021000 r--s 00006000 fd:04 1442324                    /root/.ivy2/cache/org.slf4j/slf4j-api/jars/slf4j-api-1.7.7.jar
01:49:46 7f90ea021000-7f90ea022000 r--s 00005000 fd:04 1442305                    /root/.ivy2/cache/org.slf4j/log4j-over-slf4j/jars/log4j-over-slf4j-1.7.7.jar
01:49:46 7f90ea022000-7f90ea023000 r--s 00003000 fd:04 1441913                    /root/.ivy2/cache/com.typesafe.akka/akka-slf4j_2.11/jars/akka-slf4j_2.11-2.3.11.jar
01:49:46 7f90ea023000-7f90ea03b000 r--s 001ac000 fd:04 1442168                    /root/.ivy2/cache/org.aspectj/aspectjweaver/jars/aspectjweaver-1.7.4.jar
01:49:46 7f90ea03b000-7f90ea045000 r--s 0005f000 fd:04 1315934                    /root/.ivy2/cache/ch.qos.logback/logback-core/jars/logback-core-1.1.2.jar
01:49:46 7f90ea045000-7f90ea04b000 r--s 0003d000 fd:04 1315928                    /root/.ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.2.jar
01:49:46 7f90ea04b000-7f90ea04c000 r--s 00005000 fd:04 1441959                    /root/.ivy2/cache/io.airbrake/airbrake-java/jars/airbrake-java-2.2.8.jar
<snip>

It's really a shame. I'd say I've got thousands of invocations of docker containers with alpine:3.2 at this point since we've been using this since July, but now I have to think about whether it's back to ubuntu and skinnywhale or not.

ralph-tice on 5 Jan 2016

@ralph-tice are you somehow using a 32-bit glibc on a 64-bit distro? There's something suspicious about free() complaining about 0x00000001009c8d50 being an invalid size, when that's hexadecimal for a number that's 10MB over 4GB.

delitescere on 5 Jan 2016

I'm using the same instructions from @frol above in this issue:

RUN wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" \
         "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk glibc-bin-2.21-r2.apk && \
    /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib

But I agree, that's suspicious. My docker host is x86_64 though:

$ uname -a
Linux jenkins-slave 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

and the container (after I commit and restart it) reports x86_64 also:

$ sudo docker run -it inspect bash
bash-4.3# uname -a
Linux 22dd69d75075 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 Linux

ralph-tice on 6 Jan 2016

Based on the great work by andyshinn I built a glibc apk for arm7 yesterday. I have no idea if it's 'correct' as this stuff is all very new to me but I can successfully create a Alpine Linux docker image with Oracle Java 8 with it on a Raspberry Pi 2. It's available at https://github.com/leannenorthrop/alpine-pkg-glibc/releases/tag/glibc-2.22-r1-armhf-beta.

leannenorthrop on 8 Jan 2016

@andyshinn Please, ignore my previous message, I have used the old version (# 12) of artifacts, but once I have moved on to the latest build version (# 21), everything is fine.

However, there are a couple of old issues that were around since glibc 2.21, which I have filed only today along with tested workarounds: /etc/hosts ignorance, and lack of UTF-8 locale.

frol on 11 Feb 2016

Also, for anyone else confused about which artifact to be using, I started tagging and adding them to GitHub releases page (https://github.com/andyshinn/alpine-pkg-glibc/releases). You can pull from there instead and it should be a little easier to identify what versions are out there.

andyshinn on 11 Feb 2016

Hi, everyone!

With a great help of @andyshinn I have succeeded in getting OracleJDK 8 and Mono (from Arch Linux) working on glibc 2.22 artifacts!

Could you guys give a try to the new images frolvlad/alpine-oraclejdk8:experimental and frolvlad/alpine-mono:experimental?

They should behave just the same as frolvlad/alpine-oraclejdk8:slim and frolvlad/alpine-mono:latest with only one noticeable change: the default locale is now C.UTF-8 instead of C/POSIX.

P.S. There is also frolvlad/alpine-glibc:alpine-3.3_glibc-2.22 for those who want to test the new artifacts outside of the Java/C# images.

frol on 13 Feb 2016

@frol I forked your JDK to generate a JRE image (full/clean/slim is currently defined by layering).
I'll test your great job right now.

JRE 2.22 experimental fork is here.

You are one of my favorite whales, @frol. :DDD

leodutra on 13 Feb 2016

@leodutra Yeah, I've seen your fork. I don't know how the "layering" helps you, but the main point of having all of those rm's in one RUN command was saving the size of a final image, but in your case, you will get the size of full version with a functionality of slim. BTW, is there something wrong with develar/java image (which is the recommended Alpine + Oracle JRE image in my README)?

I was contemplating creation of alpine-oraclejava image with both JDK and JRE (separated by tags). Is there somebody interested in JRE image from me?

frol on 13 Feb 2016

@frol I made the JRE for a minecraft Spigot server image I made for my family's minecraft server.
I'd like to maintain a JRE as you, releasing by branch... but I'm really new into Docker and I can't ensure much quality right now.

Learned the "few layer good practice" from some nice references, including this cheat sheet. That's the part Docker seems a litttle weird, from the sense of general software stuff. VOLUME has some weird behavior, layering causes more mem usage, layer limit and etc.

Reminds me of Internet Explorer 6 and I don't wanna live too close to this (close maybe, but not too close).

So, I'd love to see a well divided JRE Dockerfile repo made by @frol.
I've seen some... and they are not so cool (not on alpine 3.3/ bad rm usage/ no environment version variable).

You can pick my fork and start separanting the 3 layer run in 3 builds. Seems a good shortcut.

Best regards.

leodutra on 13 Feb 2016

Well... pushing to develar/java, @frol.

leodutra on 13 Feb 2016

In my testing, I used --volume to mount everything needed from the docker host to make the java app running in the container, I don't know if this works in production environment, I guess the glibc stuff has already been packaged in most linux distributions where the docker host is running, can somebody help confirm this?

I used below to start up the container:
docker run -t -i -v /lib:/lib:ro -v /lib64:/lib64:ro -v /home/jdk1.8.0_66:/root/java:ro alpine:3.3

hehailong5 on 19 Feb 2016

@hehailong5 Even if this would work, it just ruins the whole point of Docker containers. Mounting /lib inside alpine will just throw away musl libc and all binaries will become useless. Why do you need Docker or Alpine in this case at all? You can have a chroot...

frol on 19 Feb 2016

@frol you made the very good point. thanks for the confirmation. I would then turn to the docker way..

hehailong5 on 19 Feb 2016

@hehailong5 And is way more hard to work this way... you will have to
install Java in every machine, and have the same path forever. Using the
docker way, you just need to install docker, and your container will use
fewer memory space (cause there's less volumes).

leodutra on 19 Feb 2016

I have updated frolvlad/alpine-mono:experimental and frolvlad/alpine-oraclejdk8:experimental to use frolvlad/alpine-glibc:alpine-3.3_glibc-2.23 (upgraded glibc from 2.22 to 2.23). In my tests and tests conducted by some users, who reached me with a confirmation, new artifacts work just fine, so I'm going to make glibc 2.23 default if there will not be reported any issues this a week.

frol on 22 Feb 2016

@frol The latest glibc 2.23 build on Docker Hub is failing.

leodutra on 24 Feb 2016

@frol Found it. @andyshinn removed the 2.23-r0 and added 2.23-r1. :trollface:

https://github.com/andyshinn/alpine-pkg-glibc/releases

leodutra on 24 Feb 2016

@leodutra Fixed.

frol on 24 Feb 2016

Forgive my ignorance, but isn't musl expected to be compatible at the binary level with glibc (to some extent)?
If so, has someone tried to contact either the dev of musl (if musl should be compatible but isn't somehow) or the devs of OpenJDK (if OpenJDK is using some glibc specific symbols that shouldn't be relied upon) to make that compatibility work out of the box?
Having to install glibc on alpine seems to be a big workaround for a problem that could be fixed at the source.

ColinHebert on 25 Feb 2016

Yeah, I've made this questionar to myself. But I'd seen too many images
using glibc that I just let it go.

I'd like to know too.

leodutra on 26 Feb 2016

@ColinHebert OpenJDK is open-source and is available in Alpine repository, so you can use it out of the box without glibc hacks (apk add openjdk8 or openjdk7). OracleJDK, on the other hand, is closed-source, so you have to ask Oracle to release separate builds for musl libc (though it is still not very popular, so they might not be interested in investing time into this).

Is musl compatible with glibc?
...
Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

frol on 26 Feb 2016

FYI: The Alpine’s repository now provides package for JRuby, with compatible JNI dependencies. It may solve the issues you had (but I should admit that I haven’t read all this long thread). If not, then article JRuby on Alpine Linux may help.

jirutka on 9 Apr 2016

@frol @andyshinn First of all thanks for this work - I am looking to use Conda in an Alpine based container and stumbled on this discussion when I started running into problems, and I'm happy to say using the frolvlad/alpine-glibc as a base works very well, thank you both!

I am looking to use this in production, and I just want to understand the implications of using this image. The containers I will be building based on this will all be using Conda and some packages installed through PIP and some through Conda. When any of these packages requiring compilation are installed, which version of the C compiler would it use? And has this meant that any program run in these containers now runs against glibc?

elsmorian on 18 May 2016

@elsmorian I am happy that you considered Alpine as a base image for your images. I would like to start with a warning: glibc on Alpine Linux should be considered as a hack! While it is acceptable to use glibc on Alpine, it is a hard way. I, personally, use alpine-glibc in production, but there are cases when it makes life dreadful (e.g. when you integrate a weird proprietary binaries, or deploy anything with "smart" licensing). You have to use glibc-targeted compilers (there is gcc in Anaconda repos, but it is not considered as a best practice at all, still, I use it, and even maintain gcc-5 and gcc-6), and you should use glibc-compiled libraries (again, there are almost all of them in Anaconda). In the end, you will use not much of Alpine, which is a bit awkward. Good luck!)

And has this meant that any program run in these containers now runs against glibc?

No. Programs are fine, but, mixing shared libraries is very tricky (I don't exactly understand how, but sometimes this works fine). As a rule of thumb, try not to mix glibc and musl libc C extensions for Python modules.

frol on 18 May 2016

@elsmorian Why exactly do you need glibc on Alpine?

jirutka on 18 May 2016

@jirutka He pointed out the he wants to use Anaconda Python, which (binary) packages are build only against glibc. In fact, there is no need in glibc on Alpine; our need is mostly about small footprint image and glibc requirement. I guess, busybox would suit better here, but, unfortunately, it was killed :(

frol on 18 May 2016

@frol We can just make Alpine package for Anaconda (build from source against musl), can’t we?

jirutka on 18 May 2016

@jirutka You will have to start with compilation of Python (or try to trick conda to use system Python distribution (which is not a bad idea, by the way)). Next, you recompile all binary packages. BTW, Anaconda has just recently opened _some_ recipes into conda-forge initiative, yet they are still work in progress. Thus, yes, it is possible to build Anaconda infrastructure for musl, but it is a huge effort.

frol on 18 May 2016

@jirutka @frol Thanks for the info. Tricking conda into using Python already on the system is interesting but means you loose out on its abilities to pull in any version of python you want per env.

It would be great to have anaconda builds without glibc, but because of it being binary focused, you would have to rebuild all the packages :/

This seems to be working so far, will keep you updated!

elsmorian on 19 May 2016

+1

PatrickHuetter on 2 Jun 2016

Trying to run a node-oracledb project in Alpine with glibc libraries causes a number of symbol not found errors. Did anyone get it going ?

Error: Error relocating /opt/oracle/drivers/instantclient/libclntsh.so.11.1: getcontext: symbol not found
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (node_modules/oracledb/lib/oracledb.js:32:19)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (node_modules/oracledb/index.js:1:80)

What im thinking of doing is now is,

Installing glibc
Building Node and Python against glibc
And building the project specific libraries such as node-oracledb against glibc

Any thoughts anyone ?

kasunt-nixdev on 3 Jul 2016

The link to glibc seems to be dead. Any alternative source that works?

I tried here, but installing it didn't fix the original problem:
https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.21-r2/glibc-2.21-r2.apk

tpischke on 5 Aug 2016

FROM alpine:3.2

# Install cURL
RUN apk --update add wget curl ca-certificates tar && \
    curl -Ls https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.21-r2/glibc-2.21-r2.apk > glibc.apk && \
    apk add --allow-untrusted glibc.apk

# Java Version
ENV JAVA_VERSION_MAJOR 8
ENV JAVA_VERSION_MINOR 45
ENV JAVA_VERSION_BUILD 14
ENV JAVA_PACKAGE       jdk

# Download and unarchive Java
RUN mkdir /opt && curl -jksSLH "Cookie: oraclelicense=accept-securebackup-cookie"\
  http://download.oracle.com/otn-pub/java/jdk/${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-b${JAVA_VERSION_BUILD}/${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz \
    | tar -xzf - -C /opt &&\
    ln -s /opt/jdk1.${JAVA_VERSION_MAJOR}.0_${JAVA_VERSION_MINOR} /opt/jdk &&\
    rm -rf /opt/jdk/*src.zip \
           /opt/jdk/lib/missioncontrol \
           /opt/jdk/lib/visualvm \
           /opt/jdk/lib/*javafx* \
           /opt/jdk/jre/lib/plugin.jar \
           /opt/jdk/jre/lib/ext/jfxrt.jar \
           /opt/jdk/jre/bin/javaws \
           /opt/jdk/jre/lib/javaws.jar \
           /opt/jdk/jre/lib/desktop \
           /opt/jdk/jre/plugin \
           /opt/jdk/jre/lib/deploy* \
           /opt/jdk/jre/lib/*javafx* \
           /opt/jdk/jre/lib/*jfx* \
           /opt/jdk/jre/lib/amd64/libdecora_sse.so \
           /opt/jdk/jre/lib/amd64/libprism_*.so \
           /opt/jdk/jre/lib/amd64/libfxplugins.so \
           /opt/jdk/jre/lib/amd64/libglass.so \
           /opt/jdk/jre/lib/amd64/libgstreamer-lite.so \
           /opt/jdk/jre/lib/amd64/libjavafx*.so \
           /opt/jdk/jre/lib/amd64/libjfx*.so

# Set environment
ENV JAVA_HOME /opt/jdk
ENV PATH ${PATH}:${JAVA_HOME}/bin

docker run -it java /bin/sh

/ # . /opt/jdk/bin/java -version
/bin/sh: /opt/jdk/bin/java: : not found
/bin/sh: /opt/jdk/bin/java: : not found
@@@@@@@��@@@@ |� @@DDP�td��@�@1Q�td/lib64/ld-linux-x86-64.so.2GNU  GNU�t�)N�ݓ��;r�Z��?h: nonexistent directory
/bin/sh: /opt/jdk/bin/java: line 1: ELF: not found
/bin/sh: /opt/jdk/bin/java: �: not found
/bin/sh: /opt/jdk/bin/java: line 3: �: not found
/bin/sh: /opt/jdk/bin/java: syntax error: unexpected end of file (expecting ")")

tpischke on 5 Aug 2016

@tpischke Why on Earth do you still use 2.21? The project has stabilized on 2.23-r3 and has been transferred to @sgerrand https://github.com/sgerrand/alpine-pkg-glibc/releases. Anyway, just use frolvlad/alpine-glibc or at least just copy the Dockerfile if you don't want to have "external dependency".

P.S. If you need OracleJDK 8, go and have it: frolvlad/alpine-oraclejdk8

frol on 5 Aug 2016

I was just following this;

https://developer.atlassian.com/blog/2015/08/minimal-java-docker-containers/

@Tried 2.23-r2, same result.

Wasn't aware of frolvlad/alpine-glibc. Will give it a try.

tpischke on 5 Aug 2016

Same result with alpine-glibc. What am I missing?

tpischke on 5 Aug 2016

@tpischke Why do you try to source (. before the command) the Java binary as sh script? Just run it as

$ java -version

frol on 5 Aug 2016

Calling java directly didn't work for some reason with my original Dockerfile. Works beautifully with your image though. I'm up and running. Thanks for the help!

tpischke on 5 Aug 2016

@tpischke I still strongly recommend you use frolvlad/alpine-oraclejdk8 instead of crafting your own (the manuals are outdated and just useless)... There are slim, cleaned and full versions of the images, so you should be just fine.

frol on 5 Aug 2016

I very strongly recommend to use package openjdk8 instead of these nasty hacks. If some software doesn’t run on OpenJDK and does on Oracle JDK (which is quite rare), then fix that software instead of crippling Alpine.

jirutka on 5 Aug 2016

Can the java version be specified? We test and recommend specific java versions to our customers. Also, 'unofficial' external dependencies are forbidden by the project lead.

tpischke on 5 Aug 2016

Our project is very complex and getting it running on OpenJDK would likely be very costly...

tpischke on 5 Aug 2016

@tpischke Then go and fork it. Just don't copy those broken manuals, please.

frol on 5 Aug 2016

I just copied the Dockerfiles from alpine-glibc and alpine-oraclejdk8 and built the images locally myself. Works beautifully. I'll discuss migration to OpenJDK with the team, but that's not going to happen in the near term. Testing alone will be a major effort if we migrate. For now I have a brilliant working solution, thanks to you guys. Alpine Docker Images are extremely compelling.

tpischke on 5 Aug 2016

Can the java version be specified? We test and recommend specific java versions to our customers.

No, only major version (there’s package openjdk7 and openjdk8). However, you can copy the openjdk8 abuild, adjust version (and patches if needed) and build it yourself. It’s quite easy and you’ll have it fully under your control.

'unofficial' external dependencies are forbidden by the project lead.

Then why are you trying to use that glibc package on Alpine? This is unofficial hack that is _not_ supported by Alpine community. The only officially supported JRE/JDK are the mentioned openjdk packages built against musl libc.

Our project is very complex and getting it running on OpenJDK would likely be very costly...

Then you’re probably doing it wrong… Oracle JDK is just branded distribution of OpenJDK, the code base is nearly identical. That said, exceptions may exist, mainly in case of graphic applications.

If you really need OracleJDK, then use some glibc-based distribution, not Alpine. Adding glibc to Alpine is not a stable production-quality solution.

jirutka on 5 Aug 2016

@jirutka I also suggest to use OpenJDK wherever possible, but 60k pulls of my OracleJDK image suggest that it is stable enough, and I have been using it in production for quite a bit. Though, it depends on how you define the "production-quality" because Docker itself might be considered as not a production ready solution.

frol on 5 Aug 2016

We need to use Oracle Java, and it would sure be nice to use alpine linux. The fact that the official docker images are moving to alpine also plays a role in the decision. I hope alpine considers officially supporting oracle java in the future. For many java developers, openjdk is no alternative.

tpischke on 5 Aug 2016

…Docker itself might be considered as not a production ready solution.

Well, that’s very true! :)

I hope alpine considers officially supporting oracle java in the future.

Once again. Oracle JDK is a proprietary product, they don’t provide source-code of all their modifications to OpenJDK and build system, just binaries. These binaries are build against glibc (GNU C Library). Alpine Linux doesn’t use glibc, it’s based on (much better) musl libc.

Glibc and musl libc are (partially) incompatible (mainly because glibc doesn’t comply with POSIX standards). Therefore software built against glibc may not work on musl libc without recompiling. This is the case of Oracle JDK. Because it’s a proprietary product, we can’t recompile it and there’s nothing we can do about it!

libc is a very base system library, it’s _not_ yet another library you can simply install along with others. Adding support for glibc would basically mean supporting another platform. The cost of this is too high. Also it doesn’t make much sense; Alpine with glibc would not be Alpine anymore! Alpine’s “motto” is: small, simply and secure. You can’t get this with glibc.

Ask Oracle for musl support, they have the key, not Alpine.

jirutka on 5 Aug 2016

👍8

Just as musl and glibc 'should' be interchangeable, the reality is that OpenJDK and Oracle JDK also 'should' be interchangeable. They're not, and it's irresponsible to ship hacks that enable glibc in a broken way on top of a musl-based system.

ralph-tice on 30 Aug 2016

Just as musl and glibc 'should' be interchangeable, the reality is that OpenJDK and Oracle JDK also 'should' be interchangeable.

This is very different situation. glibc and musl libc are different software, they both implements POSIX standards, but the code base is totally different. Oracle JDK is just a branded distribution of OpenJDK, the source code base is the same.
Also you can easily install more JDKs side by side on one system, but not two libc.

jirutka on 30 Aug 2016

👍2 👎1

You can't safely and stably install an Oracle JDK on a system with musl libc and it needs to be prominently admitted that such is the case instead of pushing these hacks forward.

You're also wrong about OracleJDK vs OpenJDK, there are significant differences and they do impact performance and stability. They can exist side by side with glibc provided to them, but the whole point of this exercise is that OracleJDK isn't compiled against musl libc.

ralph-tice on 30 Aug 2016

👍7

I have contacted the Oracle support and I got the following statements regarding libmusl and the JRE / JDK:

The Oracle Java product organization maintains a limited number of "standard" configurations for Java and there is no plan to build it with the libmusl library. When customers request Java for other configurations, the Oracle Java product organization - Java Engineering Services (JES) - can create, certify and maintain custom version of Java for alternative O/S, special libraries, embedded architectures, older code bases, etc.

A typical engagement with JES would be: JES proposes a fixed-price engagement to do a "port" which is to deliver a certified version of Java on a non-standard platform. JES could also offer 12-months of Maintenance (renewable each year) to fix bugs and give updates.

zaunerc on 20 Oct 2016

👍6

So basically, if you need OracleJDK, you'll have to use one of the "standard" configurations for Java (eg use windows or oracle linux). If you need something else you'll have to hire JES.

ncopa on 20 Oct 2016

🎉1

"Most cross-compatible platform", they say...

The only exit would be a thin glibc facade bound to musl. And maybe this would be a kick for musl usage too.

Now we just need social engineering to convince a crazy guy for doing this.

leodutra on 22 Oct 2016

We have a new glibc package if anyone would like to test this out. You can grab the package at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk and install with apk add --allow-untrusted glibc-2.21-r2.apk. This should allow Oracle Java 8 and other glibc x86_64 native binaries to run on Alpine.

Do you provide the version compatible for ARM64 arch?

Denusdv on 17 Oct 2018

@Denusdv "no such project" at that link? :\

jtlz2 on 21 Nov 2018

Hello, I took over maintenance of the glibc package from Andy. There are
more recent versions available for download and installation at
https://github.com/sgerrand/alpine-pkg-glibc/releases. I suggest you try
there.

sgerrand on 21 Nov 2018

https://bugs.openjdk.java.net/browse/JDK-8229469

diceride on 13 Nov 2020

Docker-alpine: Alpine libs not compatible with Java 8

Most helpful comment

All 136 comments

Related issues