Skip to content

autoconf

This is what the configure script in most source distributions is made with. Sometimes you will have to generate the configure file manually, for instance the lib-p11 sources failed. My first attempts were :

setup
1
2
3
aclocal
autoconf
./configure

Which would be a good first try, but this complained about :

Error

configure: error: cannot find install-sh, install.sh, or shtool in . "."/.

The correct way to get this running would be :

full setup
1
2
3
4
5
6
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure

static libraries

The default way to force only static libraries to be built is :

static
1
./configure --disable-shared

I needed this for creating a monolith backend executable, to be able to install it in a bare docker container.

What seems to work best is this, set this in makefile :

static
1
2
LDFLAGS = -static -static-libstdc++ -static-libgcc
LDFLAGS += -Wl,-Bstatic

So that this comes before all the added libraries forcing to take the static versions. This will lead to a LOT of undefined's. Here is a script to use for dumping the contents of all installed libraries :

nm
1
2
3
4
5
6
for x in /usr/lib/x86_64-linux-gnu/*.a
do
    echo $x
    echo "=================="
    nm $x
done

It is easiest to use by dumping it into a file and then searching that file :

search for names
1
2
findlibs.sh &> libs.txt
vim libs.txt

nm will dump lines like this :

output
1
2
3
4
5
6
7
8
getaddrinfo_a.o:
                 U __assert_fail
                 U errno
                 U __gai_enqueue_request
                 U __gai_notify_only
                 U __gai_requests_mutex
0000000000000000 T getaddrinfo_a
                 U getpid

The U's are undefined, so they are probably calls to the function in question. The T entries have a (relative) offset defined and this means they are defined in the object file in question, and so you need to scroll up to the library names printed before all the symbols. That is the one you need to add.

Add it to the makefile and be prepared for a whole new set of unresolved symbols ;)

docker

When you finally did it and have a compiled executable, you can build a minimal container from 'scratch'. This is actually the mother of all images, and you can use it to as level 0.

Dockerfile
1
2
3
4
5
6
7
8
# start from scratch
FROM scratch

# copy our static linked executable
COPY release/backend backend

# tell how to run this container 
CMD ["./backend"]

However this would work for a simple helloworld program, but backend needs a LOT of dynamic libraries. I made an attempt on building backend as completely static, but there are :

  • libraries that do not come as static, where you have to build them yourself
  • libraries like p11-kit that do not even allow static builds

So that second one was a bummer, one last attempt was to strip the pqxx and proj libraries so that p11-kit was never used, but then the final executable complains about :

error
1
(.text+0x4fa): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It just means you can't just simply use a static stdc++ library for functions like gethostbyname, and much more.

See : visit for a great explanation of this,