Bug #740

Problem related to static/shared libraries and conflicts with FFTW

Added by Justin Lemkul over 9 years ago. Updated almost 7 years ago.

build system
Target version:
Affected version - extra info:
Affected version:


Many users have recently reported an error along the lines of "relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC" that has been attributed to incorrectly installing FFTW. However, it appears the during configuration, GROMACS is trying to build BOTH static and shared libraries:

The message prior to this one indicates a possible fix.

I suspect perhaps the new default behavior of trying to build shared libraries does not properly disable the building of static ones, hence the mismatch if one has, for instance, static FFTW libraries installed.

Associated revisions

Revision 977ceef5 (diff)
Added by Roland Schulz about 8 years ago

Verify that FFTW can be used with shared libraries

Fixes #740

Change-Id: If55f9bde72b1b2ce783c2a86a9bf0170a159c266

Revision 7fca425b (diff)
Added by Roland Schulz almost 7 years ago

Check zlib can actually be linked

Only use zlib compression in tng if zlib can really be linked.
This is equivalent to ee26e1264 for libxml2.

It is slightly simpler than the approach in gmxTestLibXml2
and CheckLibraryExists could be used there too.
This does not detect potential linking errors with shared
libraries similar to those solved in #740 for FFTW.

Fixes #1435

Change-Id: I5009e50b6caf810a12e71ecd83bde2edb21a2b32


#1 Updated by Roland Schulz over 8 years ago

No the issue is that FFTW needs to be build with fPIC for Gromacs to be able to be build with shared libraries. Obviously we can't automatically rebuild FFTW so the only option would be to detect the situation and print an error message that this FFTW library cannot be used with BUILD_SHARED_LIBS=on and that the user either needs to use a different FFT library or needs to disable BUILD_SHARED_LIBS.
We could detect whether FFTW is compiled with fpic using:

objdump --reloc $i 2>/dev/null | grep R_X86_64_32S 

@Christoph: Do you like this solution and could add it to FindFFTW? I think it is sufficient to fix it for 4.6 and not for 4.5.6.

#2 Updated by Roland Schulz about 8 years ago

  • Status changed from New to In Progress

#3 Updated by Teemu Murtola about 8 years ago

  • Status changed from In Progress to Closed
  • Assignee set to Roland Schulz
  • Target version set to 4.6
  • Affected version - extra info changed from 4.5.4 to 4.5.*

Looks fixed by the linked commit.

#4 Updated by Gerrit Code Review Bot almost 7 years ago

Gerrit received a related patchset '1' for Issue #740.
Uploader: Roland Schulz ()
Change-Id: I5009e50b6caf810a12e71ecd83bde2edb21a2b32
Gerrit URL:

Also available in: Atom PDF