How to install perl Kafka::Connection on alpine image - perl

I have a working UBUNTU image with this Dockerfile:
FROM perl:5.14
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update -y
RUN apt-get upgrade -y
RUN apt-get install -y libgd-dev
RUN perl -MCPAN -e 'install (Try::Tiny)'
RUN perl -MCPAN -e 'install (Kafka::Connection)'
RUN perl -MCPAN -e 'install (YAML)'
RUN perl -MCPAN -e 'install (GD::Simple)'
RUN perl -MCPAN -e 'install (GD::Graph)'
RUN perl -MCPAN -e 'install (JSON)'
RUN perl -MCPAN -e 'install (JSON::MaybeXS)'
RUN perl -MCPAN -e 'install (HTTP::Request)'
RUN perl -MCPAN -e 'install (HTTP::Response)'
RUN perl -MCPAN -e 'install (HTTP::Daemon)'
COPY run.sh /run.sh
RUN chmod +x "/run.sh"
RUN mkdir -p /code_path
WORKDIR /code_path
CMD ["/run.sh"]
I'n trying to get a slimmer alpine version like this:
FROM alpine:3.10.3
## alpine curl and wget aren't fully compatible, so we install them
## here. gnupg is needed for Module::Signature.
RUN apk update && apk upgrade
RUN apk add curl tar make gcc build-base wget gnupg
RUN mkdir -p /usr/src/perl
WORKDIR /usr/src/perl
## from perl; `true make test_harness` because 3 tests fail
## some flags from http://git.alpinelinux.org/cgit/aports/tree/main/perl/APKBUILD?id=19b23f225d6e4f25330e13144c7bf6c01e624656
RUN curl -SLO https://www.cpan.org/src/5.0/perl-5.30.0.tar.gz \
&& echo 'aa5620fb5a4ca125257ae3f8a7e5d05269388856 *perl-5.30.0.tar.gz' | sha1sum -c - \
&& tar --strip-components=1 -xzf perl-5.30.0.tar.gz -C /usr/src/perl \
&& rm perl-5.30.0.tar.gz \
&& ./Configure -des \
-Duse64bitall \
-Dcccdlflags='-fPIC' \
-Dcccdlflags='-fPIC' \
-Dccdlflags='-rdynamic' \
-Dlocincpth=' ' \
-Duselargefiles \
-Dusethreads \
-Duseshrplib \
-Dd_semctl_semun \
-Dusenm \
&& make libperl.so \
&& make -j$(nproc) \
&& true TEST_JOBS=$(nproc) make test_harness \
&& make install \
&& curl -LO https://raw.githubusercontent.com/miyagawa/cpanminus/master/cpanm \
&& chmod +x cpanm \
&& ./cpanm App::cpanminus \
&& rm -fr ./cpanm /root/.cpanm /usr/src/perl
## from tianon/perl
ENV PERL_CPANM_OPT --verbose --mirror https://cpan.metacpan.org --mirror-only
RUN cpanm Digest::SHA Module::Signature && rm -rf ~/.cpanm
ENV PERL_CPANM_OPT $PERL_CPANM_OPT --verify
RUN perl -MCPAN -e 'install (Try::Tiny)'
RUN perl -MCPAN -e 'install (Kafka::Connection)'
RUN perl -MCPAN -e 'install (YAML)'
RUN perl -MCPAN -e 'install (GD::Simple)'
RUN perl -MCPAN -e 'install (GD::Graph)'
RUN perl -MCPAN -e 'install (JSON)'
RUN perl -MCPAN -e 'install (JSON::MaybeXS)'
RUN perl -MCPAN -e 'install (HTTP::Request)'
RUN perl -MCPAN -e 'install (HTTP::Response)'
RUN perl -MCPAN -e 'install (HTTP::Daemon)'
COPY run.sh /run.sh
RUN chmod +x "/run.sh"
RUN mkdir -p /code_path
WORKDIR /code_path
CMD ["/run.sh"]
I keep getting this error
OS.c:18:10: fatal error: obstack.h: No such file or directory
#include <obstack.h> /* glibc's handy obstacks */
how do I get all the dependencies for Kafka on the image?

Alpine does not ship glibc, and obstack.h is not part of musl-dev.
Try alpine-pkg-glibc.

You could try grabbing obstack.h on Alpine by installing the newly available musl-obstack-dev package of the edge/testing repository:
apk add musl-obstack-dev --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing
Note that edge/testing packages are cutting edge and are considered experimental (as opposed to main stable package).
While Alpine (musl libc) is generally not glibc compatible, it does provide lightweight glibc compatibility in terms of convenience headers and libraries, particularly via the libc6-compat package, and packages as the aforementioned.
Tip: use Alpine's excellent package search for locating missing files. Alpine is vivid and active and sees new packages regularly. Most of the time you'll find that missing files are available in apk packages. Results for obstack.h package contents search:
https://pkgs.alpinelinux.org/contents?file=obstack.h&path=&name=&branch=edge

I eventually searched Github to find a newer alpine perl image and was greatly helped by valino's answer in arriving at this Dockerfile:
FROM alpine:3.10.3
## alpine curl and wget aren't fully compatible, so we install them
## here. gnupg is needed for Module::Signature.
RUN apk update && apk upgrade
RUN apk add --no-cache curl tar make gcc build-base wget gnupg ca-certificates g++ git gd-dev
RUN apk add --no-cache zlib zlib-dev
RUN apk add --no-cache perl perl-dev
RUN curl -L <check the link above "newer alpine perl image" for this line it was rejected> > /bin/cpanm && chmod +x /bin/cpanm
RUN cpanm App::cpm
WORKDIR /usr
RUN cpm install Try::Tiny
RUN cpm install YAML
RUN cpm install JSON
RUN cpm install JSON::MaybeXS
RUN cpm install HTTP::Request
RUN cpm install HTTP::Response
RUN cpm install HTTP::Daemon
RUN cpm install GD::Simple
RUN cpm install GD::Graph
RUN cpm install Data::HexDump::Range
RUN cpm install Proc::Daemon
RUN cpm install Test::Block
RUN cpm install Text::Colorizer
RUN cpm install Gzip::Faster
ENV PERL5LIB=/usr/local/lib/perl5
ENV PATH=/usr/local/bin:$PATH
RUN apk add --no-cache musl-obstack-dev --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing
RUN cpm install Proc::ProcessTable
RUN cpm install Kafka::Connection
COPY run.sh /run.sh
RUN chmod +x "/run.sh"
RUN mkdir -p /code_path
WORKDIR /code_path
CMD ["/run.sh"]

Related

node-poppler installation of poppler-utils and poppler-data

https://github.com/Fdawgs/node-poppler
When following the readme one thing I ran into is poppler-utils and poppler-data didn't get installed in /usr/bin. Based on that readme I'm expecting them to get installed there by default.
After running a find inside the container I found the files in /usr/share/doc. This doesn't seem right based on the readme.
How do I ensure poppler-utils and poppler-data get added into /usr/bin as expected in the readme.
Ultimately this is the code I'm instantiating:
const poppler = new Poppler('/usr/bin');
Dockerfile:
FROM docker.registry.sfg.corp.local/devops/nodejs-build-docker:16.16.60850 as build
ARG NAME
ARG IMAGE
ARG SNYK_TOKEN
ARG SNYK_ORGANIZATION
ARG SNYK_PROJECT
COPY . .
RUN apt-get update
RUN apt-get install poppler-utils -y
RUN apt-get install poppler-data -y
RUN chmod +x install-puppeteer.sh
RUN ./install-puppeteer.sh
RUN ./build.sh -n $NAME -i $IMAGE -t $SNYK_TOKEN -o $SNYK_ORGANIZATION -p $SNYK_PROJECT
FROM docker.registry.sfg.corp.local/node:16-buster
RUN apt-get update
RUN apt-get install poppler-utils -y
RUN apt-get install poppler-data -y
COPY ./install-puppeteer.sh .
RUN chmod +x install-puppeteer.sh
RUN ./install-puppeteer.sh
# add the chrome folder to the PATH
ENV PATH "$PATH:/opt/google/chrome"
COPY --from=build package.json package.json
COPY --from=build src src/
COPY --from=build node_modules node_modules/
COPY --from=build artifacts artifacts/
# Add tini to help prevent zombie chrome processes.
ADD https://github.com/krallin/tini/releases/download/v0.19.0/tini /tini
RUN chmod +x /tini
# Add user so we don't need --no-sandbox.
RUN groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser \
&& mkdir -p /home/pptruser/Downloads \
&& mkdir -p /home/pptruser/.cache \
&& mkdir -p /home/pptruser/.cache/puppeteer \
&& chown -R pptruser:pptruser /home/pptruser \
&& chown -R pptruser:pptruser /node_modules
USER pptruser
RUN chmod +x node_modules/riley/bin/riley.sh
ENTRYPOINT ["/tini", "--"]
CMD ["node_modules/riley/bin/riley.sh"]

Mac M1: Docker compose fails in vscode - mongodb-database-tools not installable

I'm running this Docker file in MAC M1:
Dockerfile
ARG VARIANT=16-bullseye
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:0-${VARIANT}
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends vim wget redis-tools
ARG MONGO_CLI_VERSION=4.4
RUN wget -qO - https://www.mongodb.org/static/pgp/server-${MONGO_CLI_VERSION}.asc | sudo apt-key add -
RUN echo "deb http://repo.mongodb.org/apt/debian buster/mongodb-org/${MONGO_CLI_VERSION} main" | tee /etc/apt/sources.list.d/mongodb-org-${MONGO_CLI_VERSION}.list
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends mongodb-mongosh \
&& apt-get clean -y && rm -rf /var/lib/apt/lists/*
RUN wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-debian11-x86_64-100.5.3.deb
RUN apt install ./mongodb-database-tools-*-100.5.3.deb
RUN su node -c "wget -O ~/.git-completion.bash https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash"
RUN su node -c "echo -e '\n# Git Completion' >> ~/.bashrc"
RUN su node -c "echo -e 'source ~/.git-completion.bash\n' >> ~/.bashrc"
The response is shown in the image attached.
On this line:
RUN wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-debian11-x86_64-100.5.3.deb
You're trying to install a package named mongodb-database-tools-debian11-x86_64-100.5.3.deb that is for Intel processors (x64_64) in your ARM64 image. That's not going to work.
MongoDB doesn't seem to offer a package for Debian on ARM64 on their download page. They do offer one for Ubuntu ARM64.
There doesn't seem to be a variant of javascript-node that builds on Ubuntu 18 Bionic, however, I think you can keep on using this Debian 11 Bullseye variant, because the version of MongoDB-database-tools for Ubuntu 16 seems to install just fine:
RUN wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu1604-arm64-100.5.3.deb
Build the image and test:
docker build -t test . ; docker run --rm test mongodump --version
mongodump version: 100.5.3
git version: 139703c0587796da96c367f365473d0266f9cede
Go version: go1.17.10
os: linux
arch: arm64
compiler: gc
If you want this image to build on both x86 and ARM, check what architecture you're on before downloading the .deb:
RUN if [ "$(arch)" = "aarch64" ] || [ "$(arch)" = "arm64" ]; then\
wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu1604-arm64-100.5.3.deb;\
else\
wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-debian11-x86_64-100.5.3.deb;\
fi;
RUN apt install ./mongodb-database-tools-*-100.5.3.deb
Try another platform for example x86_64
https://docs.docker.com/desktop/mac/apple-silicon/
Not all images are available for ARM64 architecture. You can add
--platform linux/amd64 to run an Intel image under emulation

Problem installing modules with cpanm in Perl

I am absolutely new to Perl world. I've picked up a project left behind by a former employee & trying to get it to work. The project was originally in docker form & the requirement now is to run it in a non-docker form (don't get me started on this!) The project works like a charm in it's docker form. I've made the assumption that if I were to install all the packages installed in the docker file, the script should work. In the process of installing the packages, I am bumping into issues.
While the docker image uses ubuntu, the server I am trying on now uses RHEL7
DOCKER FILE
FROM ubuntu:focal-20200703 as ubuntu
FROM ubuntu as mytool
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y -qq build-essential libssl-dev tzdata bash curl wget perl cpanminus libcrypt-ssleay-perl libnet-ssleay-perl
RUN cpanm -n Data::Printer \
Log::Log4perl \
List::Util \
Test::More \
JSON \
JSON::XS \
YAML \
YAML::XS \
GitLab::API::v4 \
IO::Socket::SSL \
HTML::HashTable \
REST::Client \
MIME::Base64 \
File::Spec \
File::Basename \
File::Path \
List::MoreUtils \
DateTime::Format::ISO8601 \
Digest::MD5
ENV TZ=Pacific/Auckland
RUN echo $TZ > /etc/timezone && ln -snf /usr/share/zoneinfo/$TZ /etc/localtime
COPY docker/context/usr/local/bin/entrypoint.sh /usr/local/bin/entrypoint.sh
COPY docker/context/usr/local/etc/mytool/mytool.env.ctmpl /usr/local/etc/mytool/mytool.env.ctmpl
RUN mkdir -p /usr/local/bin /usr/local/bin/cache.d
WORKDIR /usr/local/bin
COPY mytool /usr/local/bin/
COPY lib/ /usr/local/bin/lib
# Container pilot obligatory parameters START
ENV SERVICE_NAME=mytool
ENV SERVICE_PRE_EXEC=/bin/true
ENV SERVICE_HEALTHCHECK_EXEC="test -f /usr/local/etc/mytool/mytool.env"
ENV SERVICE_TEMPLATE_CONFIG_PAIRS=/usr/local/etc/mytool/mytool.env.ctmpl:/usr/local/etc/mytool/mytool.env
EXPOSE 8080
ENTRYPOINT [""]
CMD ["/usr/local/bin/entrypoint.sh"]
# Container pilot obligatory parameters END
I've installed build-essential libssl-dev tzdata bash curl wget perl cpanminus libcrypt-ssleay-perl libnet-ssleay-perl successfully.
Problem is with cpanm stuff from the docker file
[root#npcrver01 home]# cpanm Log::Log4perl
! Finding Log::Log4perl on cpanmetadb failed.
! cannot open file '/root/.cpanm/sources/http%www.cpan.org/02packages.details.txt.gz': No such file or directory opening compressed index
! Couldn't find module or a distribution Log::Log4perl ()
Please could someone help me here
gosh it's the proxy setting. I had to do
export https_proxy=http://<IP>:<port>
export http_proxy=http://<IP>:<port>
export HTTPS_PROXY=http://<IP>:<port>
export HTTP_PROXY=http://<IP>:<port>
Everything is working fine now

How to make Python version executables global across multiple pyenv-virtualenv virtual environments

A pyenv Python version (e.g. 3.10.4) has the "normal" expected Python executables associated with it (e.g., pip, 2to3, pydoc)
$ ls "${PYENV_ROOT}/versions/3.10.4/bin"
2to3 idle idle3.10 pip3 pydoc pydoc3.10 python-config python3-config python3.10-config
2to3-3.10 idle3 pip pip3.10 pydoc3 python python3 python3.10 python3.10-gdb.py
and a pyenv-virtualenv virtual environment has only the executables that one would a get inside the virtual environment directory structure
$ pyenv virtualenv 3.10.4 venv
$ ls "${PYENV_ROOT}/versions/venv"
bin include lib lib64 pyvenv.cfg
$ ls "${PYENV_ROOT}/versions/venv/bin/"
Activate.ps1 activate activate.csh activate.fish pip pip3 pip3.10 pydoc python python3 python3.10
by default after creation, the venv virtual environment doesn't know about executables of the Python version that it is associated to, like 2to3
$ pyenv activate venv
(venv) $ 2to3 --help
pyenv: 2to3: command not found
The `2to3' command exists in these Python versions:
3.10.4
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
so to allow for a virtual environment like venv to have access to these executables you add both it and the Python that created it to pyenv global so that pyenv will "fall back" to the Python version when the executable isn't found
(venv) $ pyenv deactivate
$ pyenv global venv 3.10.4
(venv) $ pyenv global
venv
3.10.4
(venv) $ 2to3 --help | head -n 3
Usage: 2to3 [options] file|dir ...
Options:
This pattern works for one virtual environment, but how do you maintain access to executables like 2to3 (or pipx as seen below`) when you have multiple virtual environments in play?
(venv) $ pyenv virtualenv 3.10.4 example && pyenv activate example
(example) $ 2to3
pyenv: 2to3: command not found
The `2to3' command exists in these Python versions:
3.10.4
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
Reproducible example
Using the following Dockerfile
FROM debian:bullseye
SHELL ["/bin/bash", "-c"]
USER root
RUN apt-get update -y && \
apt-get install --no-install-recommends -y \
make \
build-essential \
libssl-dev \
zlib1g-dev \
libbz2-dev \
libreadline-dev \
libsqlite3-dev \
wget \
curl \
llvm \
libncurses5-dev \
xz-utils \
tk-dev \
libxml2-dev \
libxmlsec1-dev \
libffi-dev \
liblzma-dev \
g++ && \
apt-get install -y \
git && \
apt-get -y clean && \
apt-get -y autoremove && \
rm -rf /var/lib/apt/lists/*
# Install pyenv and pyenv-virtualenv
ENV PYENV_RELEASE_VERSION=2.3.0
RUN git clone --depth 1 https://github.com/pyenv/pyenv.git \
--branch "v${PYENV_RELEASE_VERSION}" \
--single-branch \
~/.pyenv && \
pushd ~/.pyenv && \
src/configure && \
make -C src && \
echo 'export PYENV_ROOT="${HOME}/.pyenv"' >> ~/.bashrc && \
echo 'export PATH="${PYENV_ROOT}/bin:${PATH}"' >> ~/.bashrc && \
echo 'eval "$(pyenv init -)"' >> ~/.bashrc && \
. ~/.bashrc && \
git clone --depth 1 https://github.com/pyenv/pyenv-virtualenv.git $(pyenv root)/plugins/pyenv-virtualenv && \
echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc
# Install CPython
ENV PYTHON_VERSION=3.10.4
RUN . ~/.bashrc && \
echo "Install Python ${PYTHON_VERSION}" && \
PYTHON_MAKE_OPTS="-j8" pyenv install "${PYTHON_VERSION}"
# Make 'base' virtual envirionment, add it and its Python version to global for
# executables like 2to3 or pipx to be findable
# c.f. https://github.com/pyenv/pyenv-virtualenv/issues/16#issuecomment-37640961
# and then install pipx into the 'base' virtual environment and use pipx to install
# pepotron
RUN . ~/.bashrc && \
pyenv virtualenv "${PYTHON_VERSION}" base && \
echo "" && echo "Python ${PYTHON_VERSION} has additional executables..." && \
ls -lh "${PYENV_ROOT}/versions/${PYTHON_VERSION}/bin" && \
echo "" && echo "...compared to 'base' virtualenv made with Python ${PYTHON_VERSION}" && \
ls -lh "${PYENV_ROOT}/versions/base/bin" && \
echo "" && echo "...because 'base' is actually a symlink" && \
ls -lh "${PYENV_ROOT}/versions/" && \
pyenv global base "${PYTHON_VERSION}" && \
python -m pip --quiet install --upgrade pip setuptools wheel && \
python -m pip --quiet install pipx && \
python -m pipx ensurepath && \
eval "$(register-python-argcomplete pipx)" && \
pipx install pepotron
WORKDIR /home/data
built with
docker build . --file Dockerfile --tag pyenv/multiple-virtualenvs:debug
it can be run with the following to demonstrate the problem
$ docker run --rm -ti pyenv/multiple-virtualenvs:debug
(base) root#26dfa530cd82:/home/data# pyenv global
base
3.10.4
(base) root#26dfa530cd82:/home/data# 2to3 --help | head -n 3
Usage: 2to3 [options] file|dir ...
Options:
(base) root#26dfa530cd82:/home/data# pipx list
venvs are in /root/.local/pipx/venvs
apps are exposed on your $PATH at /root/.local/bin
package pepotron 0.6.0, installed using Python 3.10.4
- bpo
- pep
(base) root#26dfa530cd82:/home/data# pep 3.11
https://peps.python.org/pep-0664/
(base) root#26dfa530cd82:/home/data# pyenv virtualenv 3.10.4 example
(base) root#26dfa530cd82:/home/data# pyenv activate example
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
(example) root#26dfa530cd82:/home/data# 2to3
pyenv: 2to3: command not found
The `2to3' command exists in these Python versions:
3.10.4
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
(example) root#26dfa530cd82:/home/data# pipx
pyenv: pipx: command not found
The `pipx' command exists in these Python versions:
3.10.4/envs/base
base
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
So how can one have something like pipx, that is designed to be installed globally, work globally if it is installed in a pyenv-virtualenv virtual environment so that you don't have to have anything installed with pip in the system Python?
It would seem that instead of ever using pyenv activate to activate a virtual environment you would need to deactivate any virtual environments and then only use pyenv global <virtual environment name> <virtual environment Python version> to effectively switch environments. I assume that can't be the only way to use Python version executables inside of a virtual environment, as that seems like that would remove the point of having a separate pyenv activate CLI API for pyenv-virtualenv.
You can directly execute the pipx binary in the pyenv prefix, it should work correctly.
Pyenv's shims mechanism isn't really designed for global binaries like this. I naively expected that the global environment would act as fallback when a local environment doesn't have an installed binary, but I think pyenv only looks at the system Python before falling back to $PATH.
So, if you don't install pipx into system (which, if you're not installing a system pip, I doubt you're doing), then the naive fallback doesn't work.
An alternative is to run pyenv with a temporary environment, i.e.
PYENV_VERSION=my-pipx-env pyenv exec pipx.
I'd want to make this an executable, so I'd suggest adding something like this into a special PATH directory that takes precedence from the pyenv paths:
#!/usr/bin/env bash
set -eu
export PYENV_VERSION="pipx"
exec "${PYENV_ROOT}/libexec/pyenv" exec pipx "$#"
Although, I'd be tempted to forgo the whole activation logic and just directly exec the pipx binary from the environment /bin to avoid running into any shell configuration errors.

Running Mkbootstrap for DBI () => DBIXS.h:22:20: fatal error: EXTERN.h: No such file or directory

I try to install MHA node on a docker container based on Alpine. The container has perl, make and gcc via apk. :
RUN apk add --update perl make gcc
A prerequisite for MHA node is DBD::mysql. The command
perl -MCPAN -e 'install DBD::mysql'
results in the above given error. Google does know nothing about it.
The following commands, needed for MHA manager, do run fine, however:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
The problem obviously is related to DBI:
Running Mkbootstrap for DBI ()
chmod 644 "DBI.bs"
"/usr/bin/perl" -p -e "s/~DRIVER~/Perl/g" ./Driver.xst > Perl.xsi
"/usr/bin/perl" "/usr/share/perl5/core_perl/ExtUtils/xsubpp" -typemap "/usr/share/perl5/core_perl/ExtUtils/typemap" -typemap "typemap" Perl.xs > Perl.xsc && mv Perl.xsc Perl.c
cc -c -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fomit-frame-pointer -DVERSION=\"1.636\" -DXS_VERSION=\"1.636\" -fPIC "-I/usr/lib/perl5/core_perl/CORE" -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter Perl.c
In file included from Perl.xs:7:0:
DBIXS.h:22:20: fatal error: EXTERN.h: No such file or directory
compilation terminated.
Makefile:625: recipe for target 'Perl.o' failed
make: *** [Perl.o] Error 1
TIMB/DBI-1.636.tar.gz
/usr/bin/make -- NOT OK
What can I do to resolve it?
Works with Ubuntu 14.04 after install make gcc
You need the libperl headers to be able to build certain modules, including DBI. On Alpine it looks like they are provided by the package perl-dev.
From http://www.perlmonks.org/bare/?node_id=486526
EXTERN.h is part of the perl C API which is needed for embedding the interpreter and building XS modules. The official perl distribution contains all these files, but many linux distributions don't bundle it as part of the base perl package (some even leave out a lot of core modules). There should be one or more additional packages for your distribution that supply the C API files. They're usually called "perl-dev" or something like it. (From googling, it looks like the mandrage package is "perl-devel-5.*.rpm")
So the solution looked like to add perl-dev to the apk add command, but this was not enough:
In file included from DBIXS.h:23:0,
from Perl.xs:7:
/usr/lib/perl5/core_perl/CORE/perl.h:699:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
Makefile:628: recipe for target 'Perl.o' failed
Ok, some more googling resulted in addin musl-dev as well. Now that works:
FROM alpine
ENV MHA_NODE_VERSION=0.54 \
MHA_MANAGER_VERSION=0.55
COPY ./mha/* /tmp/
# mha4mysql-manager-0.55.tar.gz
# mha4mysql-node-0.54.tar.gz
RUN apk add --update perl perl-dev musl-dev make gcc \
&& perl -MCPAN -e 'install DBD::mysql' \
&& perl -MCPAN -e "install Config::Tiny" \
&& perl -MCPAN -e "install Log::Dispatch" \
&& perl -MCPAN -e "install Parallel::ForkManager" \
&& cd /tmp \
&& tar -zxf mha4mysql-node-${MHA_NODE_VERSION}.tar.gz \
&& cd mha4mysql-node-${MHA_NODE_VERSION}/ \
&& perl Makefile.PL \
&& make \
&& make install \
&& cd /tmp \
&& tar -zxf mha4mysql-manager-${MHA_MANAGER_VERSION}.tar.gz \
&& cd mha4mysql-manager-${MHA_MANAGER_VERSION}/ \
&& perl Makefile.PL \
&& make \
&& make install \
&& apk del make gcc musl-dev perl-dev \
&& rm -rf /var/cache/apk/*
ENTRYPOINT ["/usr/bin/perl", "-de0"]