Alpine libs not compatible with Java 8

[giovannicandido]

Trying to install oracle JDK 8 and I get this error when run:

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

The ldd command give the result:

ldd /opt/jdk/bin/java
    /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libjli.so => /opt/jdk/bin/../lib/amd64/jli/libjli.so (0x7f8da07e0000)
    libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
Error relocating /opt/jdk/bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found

What could be done?

[jumanjiman]

Check out frolvlad/alpine-glibc

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

[frol]

@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/*

[ozbillwang]

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.

[frol]

@SydOps Try adding conda install libgcc.

[ozbillwang]

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]

@frol

Yes, the problem is fixed, thanks a lot

[andyshinn]

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.

[frol]

@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.

[antoineco]

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

[andyshinn]

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.

[antoineco]

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

[andyshinn]

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.

[hwangbible]

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.

[frol]

@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"

[hwangbible]

@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?

[frol]

@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.

[hwangbible]

@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?

[frol]

@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.

[hwangbible]

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

[sdurrheimer]

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

[sdurrheimer]

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

[antoineco]

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

[sdurrheimer]

@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

[antoineco]

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

[sdurrheimer]

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/

[magiconair]

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.

[frol]

@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.

[ralph-tice]

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.

[delitescere]

@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.

[ralph-tice]

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

[frol]

@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.

[andyshinn]

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.

[frol]

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.

[leodutra]

@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

[frol]

@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?

[leodutra]

@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]

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

[hehailong5]

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

[frol]

@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...

[hehailong5]

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

[leodutra]

@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).

[frol]

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.

[leodutra]

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

[leodutra]

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

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

[frol]

@leodutra Fixed.

[ColinHebert]

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.

[leodutra]

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.

[frol]

@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.

[jirutka]

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.

[elsmorian]

@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?