Re: [easybuild] FFTW dynamic libraries?

2016-10-13 Thread Kenneth Hoste

Hi Pablo,

On 13/10/16 14:06, Pablo Escobar Lopez wrote:

Hi Kenneth,

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:

https://gist.github.com/pescobar/90cf77b0bcb5c1494b18365ce50a78cb

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?


Note that I'm aware of, it's probably that nobody has needed the dynamic 
libraries specifically...


So, a PR to add --enable-shared would be nice. ;-)
Ideally, also with updating the sanity_check_paths...



K.


regards,
Pablo.



2016-10-13 12:47 GMT+02:00 Kenneth Hoste >:


Hi Pablo,

On 13/10/16 11:48, Pablo Escobar Lopez wrote:

Hi,

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"

to

common_configopts = "--enable-threads --enable-openmp --with-pic
*_--enable-shared_*"

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).


regards,

Kenneth




--
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch




Re: [easybuild] FFTW dynamic libraries?

2016-10-13 Thread Pablo Escobar Lopez
Hi Kenneth,

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:
https://gist.github.com/pescobar/90cf77b0bcb5c1494b18365ce50a78cb

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?

regards,
Pablo.



2016-10-13 12:47 GMT+02:00 Kenneth Hoste :

> Hi Pablo,
>
> On 13/10/16 11:48, Pablo Escobar Lopez wrote:
>
> Hi,
>
> 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"
>
> to
>
> common_configopts = "--enable-threads --enable-openmp --with-pic
> *--enable-shared*"
>
> 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).
>
>
> regards,
>
> Kenneth
>
>


-- 
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch


Re: [easybuild] FFTW dynamic libraries?

2016-10-13 Thread Kenneth Hoste

Hi Pablo,

On 13/10/16 11:48, Pablo Escobar Lopez wrote:

Hi,

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"

to

common_configopts = "--enable-threads --enable-openmp --with-pic 
*_--enable-shared_*"


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).



regards,

Kenneth



[easybuild] FFTW dynamic libraries?

2016-10-13 Thread Pablo Escobar Lopez
Hi,

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"

to

common_configopts = "--enable-threads --enable-openmp --with-pic
*--enable-shared*"

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?

regards,
Pablo.

-- 
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch