Static build for docker external image inclusion

[donkon]

We would like to include the bmx tool binaries (bmxtranswrap, mxf2raw, ...) in our own docker image.

This can be done quite easy by Multistage builds:

COPY --from=bmxtools:latest /usr/local/bin /usr/local/bin

This requires that we either

1. include the runtime dependencies in our image too (liburiparser-dev, ...) or
2. rely on a complete static linked binary without any runtime dependencies

Option 2 seems to be more easy on the "inclusion" side, so tried to build statically linked binaries by adding -DBUILD_SHARED_LIBS=OFF to the Dockerfile, but this only eliminates the libMXF libs, other libs (e.g. libexpat) are still required:

root@db3b4306a4f7:/usr/local/bin# ldd mxf2raw 

	linux-vdso.so.1 (0x00007fffad5e8000)
	libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f12973a1000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1297372000)
	liburiparser.so.1 => /usr/lib/x86_64-linux-gnu/liburiparser.so.1 (0x00007f1297355000)
        .....

My questions are:

• is option 2 the best choice?
• how to build statically linked binaries?
• can the Dockerfile be extended with ARGs, so that the Copy, configure and make install step can be modified?

[philipnbbc]

I think an option 3, where given your own Dockerfile, you copy the build stage from the bmx Dockerfile and merge in the "runtime" stage that copies the bmx libs and executables from the build stage and installs the dependency packages (plus any other changes you need). I assume that you want to use the ARGS to add more stuff to install? It seems to me that creating a new Dockerfile might be cleaner than adding hooks to modify the bmx Dockerfile.

[donkon]

Let's consider option 2 again (not sure if you got me right):

ARGs in the bmx Dockerfile allow anybody to customize the make install step:

# Copy, configure and make install
COPY . bmx
ARG BUILD_SHARED_LIBS=ON
ARG LIBMXF_BUILD_ARCHIVE=ON
ARG BMX_BUILD_WITH_LIBCURL=ON
RUN mkdir build && cd build && \
    cmake -G "Unix Makefiles" \
        -DCMAKE_INSTALL_PREFIX=/build/install \
        -D$BMX_BUILD_WITH_LIBCURL \
        -D$LIBMXF_BUILD_ARCHIVE \
        -D$BUILD_SHARED_LIBS \

So in the bmx project I would run

docker build --build-arg BUILD_SHARED_LIBS=OFF our-registry/bmxtools .

to build our bmxtools image flavour containing static linked binaries, push the bmxtools image in our container registry and add

COPY --from=our-registry/bmxtools:latest /usr/local/bin /usr/local/bin

to my own Dockerfile to include the binaries.

This brings me back to the question "how to build statically linked binaries", so that the runtime dependencies are also statically linked (liburiparser-dev, uuid-dev, libexpat1-dev)? In my own image, I just want to include the binaries, what I don't want is to re-define external runtime dependencies (we also use other cli based tools like bmx which might conflict with the libs)

[philipnbbc]

Ah ok. I hadn't spotted that you were copying from an external image rather than from an internal build stage and so intend to have a separate bmxtools image.

I'm don't know what changes would need to be made to produce binaries with minimal runtime dependencies.

A new config option that uses something like cmake's FindPkgConfig instead of FindCURL, FindEXPAT would provide the <prefix>_STATIC results (from pkg-config --static ...) that has the location of the static library. Pkg config is already used for uriparser, https://github.com/bbc/bmx/blob/main/cmake/ext_uriparser.cmake#L50, and could be adapted for the static library config option case.

The issues I see here is that uriparser package doesn't provide a static library, and curl and expat may have dependencies that are not static libraries and so you'd need to deal those dependencies as well.

What you might need to do is build the dependencies from source to get static libraries, possibly including dependencies of those dependencies. The BMX_BUILD_EXPAT_SOURCE and BMX_BUILD_EXPAT_SOURCE options can be used. I don't know how far that will get you. There isn't a build-from-source option for curl.

There are also static builds of ffmpeg that might provide some clues how to do it.