Build Tricks

This page collects some known build errors and trick how to fix them

Any platform

Header files of the dependencies can't be found

Sometimes the build system can't find the header files of the dependencies, even if they're properly installed. When this happens, you have to tell the C/C++ preprocessor where the files are by setting the CPPFLAGS environment variable:

export CPPFLAGS="-I${prefix}/include"
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target}
make -j${nprocs}
make install

See for example Cairo build script.

Libraries of the dependencies can't be found

Like in the section above, it may happen that the build system fails to find the libraries of the dependencies, even when they're installed to the right place. In these case, you have to inform the linker where the libraries are by setting the LDFLAGS environment variable:

export LDFLAGS="-L${libdir}"
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target}
make -j${nprocs}
make install

See for example libwebp build script (in this case this was needed only when building for FreeBSD).

Running foreign executables

The build environment provided by BinaryBuilder is a x86_64-linux-musl, and it can run executables for the following platforms: x86_64-linux-musl, x86_64-linux-gnu, i686-linux-gnu. For all other platforms, if the build system tries to run a foreign executable you'll get an error, usually something like

./foreign.exe: line 1: ELF��
                       @@xG@8@@@@@@���@�@@����A�A����A�A���@�@: not found
./foreign.exe: line 1: syntax error: unexpected end of file (expecting ")")

This is one of worst cases when cross-compiling, and there isn't a simple solution. You have to look into the build process to see if running the executable can be skipped (see for example the patch to not run dot in #351), or replaced by something else. If the executable is a compile-time only utility, try to build it with the native compiler (see for example the patch to build a native mkdefs in #351)

FreeBSD

undefined reference to `backtrace_symbols'

If compilation fails because of the following errors

undefined reference to `backtrace_symbols'
undefined reference to `backtrace'

then you need to link to execinfo:

if [[ "${target}" == *-freebsd* ]]; then
    export LDFLAGS="-lexecinfo"
fi
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target}
make -j${nprocs}
make install

See for example #354.

Windows

Libtool refuses to build shared library because of undefined symbol

When building for Windows, sometimes libtool refuses to build the shared library because of undefined symbols. When this happens, compilation is successful but BinaryBuilder's audit can't find the expected LibraryProducts.

In the log of compilation you can usually find messages like

libtool: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries; building static only

or

libtool:   error: can't build i686-w64-mingw32 shared library unless -no-undefined is specified

In these cases you have to pass the -no-undefined option to the linker, as explicitly suggested by the second message.

Doing this properly is a bit tricky: I couldn't make CFLAGS=-Wl,-no-undefined work, instead setting LDFLAGS=-no-undefined before ./configure make this fail (because it will run a command like cc -no-undefined conftest.c, which upsets the compiler). What I use to do is to pass LDFLAGS=-no-undefined only to make:

FLAGS=()
if [[ "${target}" == *-mingw* ]]; then
    FLAGS+=(LDFLAGS="-no-undefined")
fi
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target}
make -j${nprocs} "${FLAGS[@]}"
make install

See for example #170, #354.