I needed this because while compiling an internal application I noticed
that it requires "libfftw3f_threads.so". As my compute nodes have
fftw-devel rpm installed the build system was using this library from the
system. After recompiling my FFTW module with --enable-shared the
application uses the libfftw3f_threads.so lib provided by my FFTW module
instead of the system one.
These are the contents of my $EBROOTFFTW/lib/ folder when compiling with
--enable-shared. It includes both the static and dynamic libraries:
IMHO, it makes sense that the FFTW installation in easybuild provides both
the dynamic and static libraries so applications depending on the fftw
dynamic libs can use the easbuild FFTW module. Does this have any drawback
I am missing?
2016-10-13 12:47 GMT+02:00 Kenneth Hoste <kenneth.ho...@ugent.be>:
> Hi Pablo,
> On 13/10/16 11:48, Pablo Escobar Lopez wrote:
> I have noticed that FFTW-3.3.3-gompi-1.4.10.eb is not building the
> dynamic FFTW libraries. For this I think the fix would be to change
> configopts from this:
> common_configopts = "--enable-threads --enable-openmp --with-pic"
> common_configopts = "--enable-threads --enable-openmp --with-pic
> Is there any reason why the provided FFTW easyconfig is not building the
> dynamic libraries. Would it be safe to apply this change so the dynamic
> libs are built? or is there any issue which could be triggered by doing
> this change which I am missing?
> It's probably just because nobody has had a strict need for the dynamic
> libraries yet? What's your use case for needing them?
> The only thing I can think of is that by using --enable-shared the static
> libraries may not be built anymore, but you'll have to check that (and the
> sanity check should fail anyway in that case).
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics