[gmx-developers] Windows64 builds and gsl linking
Mirco Wahab
mirco.wahab at chemie.tu-freiberg.de
Mon Feb 20 23:20:18 CET 2012
Hi folks,
after I managed to build native VS2010/x64 versions of
- libxml2/libiconv
- fftw3
- gsl/cblas
into dlls, I tried to connect this w/Gromacs into a
working executable.
Thanks to the cmake build system adapted in 4.5.5,
this was succesful in the end.
The following problem was encountered during the build:
- the few modules that actually use gsl
(geminate.c, gmx_hbond.c, gmx_kinetics.c)
define "HAVE_LIBGSL" before including the
corresponding headers. This is fine, but
for the windows build, there should be another
defined variable to indicate dll or static
gsl linkage *to the gsl headers*, like
#ifdef HAVE_LIBGSL
#define GSL_DLL <-------- default (otherwise GSL_STATIC)
#include <gsl/gsl_multimin.h>
...
This allows to redefine the function signature during
compilation, otherwise symbols won't be found by the
executables (g_analyze etc.) if accessed through another
library (gmxana).
- after manually inserting a #define GSL_DLL line into the
three modules indicated above, all tools were linking fine.
Besides, in gmx_kinetics.c resides a function
static char *itoa(int i)
which uses the name of the more-or-less popular C library function
itoa() (not ANSI, but supported by Visual Studio and invoked by
stdlib.h).
Thanks & Regards
M.
More information about the gromacs.org_gmx-developers
mailing list