[gmx-developers] help needed: static builds with cmake

[Szilárd Páll]

Hi,

I've been trying to implement a feature which would enable building
static binaries with cmake, but I've got to a point where I got
completely stuck and I am writing as a desperate move hoping that
someone of you will come up with a good idea.

What I've done is a 2 stage solution for making static binaries (this
seems to be by far the simplest way):

  1) an option GMX_PREFER_STATIC_LIBS which tells cmake to prefer
picking up ".a"-s when searching for libraries.

  2) telling cmake to use static system libraries.

1) works fine, but referring to file extensions/endings might not be
general enough. Making it more general/robust would require rewriting
the way external libraries are treated: instead of adding them with
full path we'd need to add -Lpath -llibname separately. However, this
needs quite a bit more time than I have now...

2) Should work with the target property LINK_SEARCH_END_STATIC which
essentially puts a -Wl,-Bstatic (for gcc on Linux, but it's supposed
to work on many platforms) at the end of the final link call argument
list. This results in having the system libs linked in statically. Now
the only problem is, that if I use this argument, the linking fails
with this error:

$ /usr/bin/gcc   -Wall -Wno-unused   -fomit-frame-pointer
-finline-functions -funroll-all-loops  -O3 -DNDEBUG
CMakeFiles/mdrun.dir/gctio.c.o CMakeFiles/mdrun.dir/ionize.c.o
CMakeFiles/mdrun.dir/runner.c.o CMakeFiles/mdrun.dir/do_gct.c.o
CMakeFiles/mdrun.dir/repl_ex.c.o CMakeFiles/mdrun.dir/xutils.c.o
CMakeFiles/mdrun.dir/md.c.o CMakeFiles/mdrun.dir/mdrun.c.o
CMakeFiles/mdrun.dir/genalg.c.o CMakeFiles/mdrun.dir/md_openmm.c.o  -o
mdrun -rdynamic -ldl -lm libgmxpreprocess.a ../mdlib/libmd.a
../gmxlib/libgmx.a -ldl -lm -lpthread
/home/pszilard/tools/fftw-3.2.2/lib/libfftw3f.a -Wl,-Bstatic
-Wl,-rpath,/usr/local/gromacs/lib
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

Obviosly, libgcc_s.a is not available...

As a very dirty workaround could be the "-static" gcc option which
should work on Linux with gcc and icc, but it's surely not
portable-enough to work on more exotic systems. Moreover, this
argument makes gcc very much unforgiving, so if any shared libs are
picked up in stage 1) gcc will simply refuse to compile. I also get
some warnings, and by looking at them I think they are not a good
sign:

$ /usr/bin/gcc   -Wall -Wno-unused   -fomit-frame-pointer
-finline-functions -funroll-all-loops  -O3 -DNDEBUG
CMakeFiles/mdrun.dir/gctio.c.o CMakeFiles/mdrun.dir/ionize.c.o
CMakeFiles/mdrun.dir/runner.c.o CMakeFiles/mdrun.dir/do_gct.c.o
CMakeFiles/mdrun.dir/repl_ex.c.o CMakeFiles/mdrun.dir/xutils.c.o
CMakeFiles/mdrun.dir/md.c.o CMakeFiles/mdrun.dir/mdrun.c.o
CMakeFiles/mdrun.dir/genalg.c.o CMakeFiles/mdrun.dir/md_openmm.c.o  -o
mdrun -rdynamic -ldl -lm libgmxpreprocess.a ../mdlib/libmd.a
../gmxlib/libgmx.a -ldl -lm -lpthread
/home/pszilard/tools/fftw-3.2.2/lib/libfftw3f.so -static
-Wl,-rpath,/usr/local/gromacs/lib
../gmxlib/libgmx.a(vmddlopen.c.o): In function `vmddlopen':
vmddlopen.c:(.text+0x36): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/bin/ld: attempted static link of dynamic object
`/home/pszilard/tools/fftw-3.2.2/lib/libfftw3f.so'
collect2: ld returned 1 exit status

I'd be grateful for tips on how to fix the issue with 2), but I'm open
for short and portable (and preferably elegant) solutions.

Cheers,
--
Szilárd