Problem related to static/shared libraries and conflicts with FFTW
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.
Verify that FFTW can be used with shared libraries
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.
#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.