[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

Thanks & Regards


More information about the gromacs.org_gmx-developers mailing list