[CLAM] fftw and configure

[Rhywek]

Miguel Ramírez Jávega wrote:

>Hi,
>
>  
>
>>Why didn't you add this --enable-shared in fftw configure? From what I
>>see CLAM needs .so files, so it seems necessary for me.
>>    
>>
>
>Last time I tried to build and install fftw from sources, I did not need
>to specify the --enable-shared option. That was a lot of time ago human
>memory is faulty. So I have tried to replicate your problems by
>installing the thing myself again and trying 0.8.0 configure script.
>
>What I found was that when *not* specifying the --enable-shared option,
>and in consequence only generating object archives (.a files) the
>configure script gets two link errors when actually testing compiling
>and linking against the present fftw version:
>
>configure:4488: g++ -o conftest -g -O2   -lfftw -lrfftw conftest.cc  >&5
>/tmp/ccUcImST.o(.text+0x20): In function `main':
>/home/mramirez/Sandboxes/CLAM/build/conftest.cc:28: undefined reference
>to `fftw_create_plan'
>/tmp/ccUcImST.o(.text
>+0x3b):/home/mramirez/Sandboxes/CLAM/build/conftest.cc:29: undefined
>reference to `rfftw_create_plan'
>/tmp/ccUcImST.o(.text
>+0x40):/home/mramirez/Sandboxes/CLAM/build/conftest.cc:30: undefined
>reference to `fftw_sizeof_fftw_real'
>
>as you can see it is not that 'CLAM requires .so files' but that for
>some strange reason, linking against static libraries fails.
>
>That's extremely weird to say the least since those symbols are in the
>binaries:
>
>$ objdump -t /usr/lib/libfftw.a | egrep fftw_create_plan
>00000150 g     F .text  00000099 fftw_create_plan_specific
>000001f0 g     F .text  00000181 fftw_create_plan
>00000000         *UND*  00000000 fftw_create_plan
>00000000         *UND*  00000000 fftw_create_plan_specific
>00000000         *UND*  00000000 fftw_create_plan
>00000000         *UND*  00000000 fftw_create_plan
>
>$ objdump -t /usr/lib/libfftw.a | egrep fftw_sizeof_fftw_real
>00000bc0 g     F .text  00000006 fftw_sizeof_fftw_real
>
>
>$ objdump -t /usr/lib/librfftw.a | egrep rfftw_create_plan
>00000160 g     F .text  00000099 rfftw_create_plan_specific
>00000200 g     F .text  0000017b rfftw_create_plan
>00000000         *UND*  00000000 rfftw_create_plan
>00000000         *UND*  00000000 rfftw_create_plan
>
>maybe the *UND* flags might be giving an explanation for this problem.
>But since I am not so much knowledgeable about internals of gnu linker I
>completely ignore the meaning (and reason for this).
>
>Weirdest of all is the fact that when linking against dynamic libraries
>instead of the static ones, everything runs smoothly. 
>
>This definitely seems an issue related with fftw-2.1.5 - or libtool or
>Ifni knows what.
>
>So I am sorry if I misled you because of not testing myself exhaustively
>your problem and relying on my memories of past problems reported to the
>list.
>
>  
>
So from what I see I will need to use shared libraries solution, as this
is the only one I managed to make work.

>>Why do you give --enable-float and --enable-type-prefix? I would expect that it will build the fftw with single instead of double precision and it will be called sfftw instead of fftw. Actually I believe this is one correct step of two, i.e. I still need double precision, right? (I would very much prefer it)
>>    
>>
>
>Because I did not fully understand your question. I was assuming you
>were having trouble with the single-precision fftw version.
>
>Actually both of them (single and double) are required by default.
>Unless you specify to CLAM's configure the --without-fftw argument, to
>bypass double-precision fftw presence check, or the --without-sfftw one,
>to bypass single-precision fftw presence check.
>
>  
>
>>Where the first one will be double precision fftw named fftw and the second one single precision fftw named sfftw.
>>The only problem I can see here is that even though the libraries have distinct names, the header files have the same names and sfftw headers would overwrite fftw headers... for example (after making both, here is the diff of them):
>>
>>40c40
>>< /* #undef FFTW_ENABLE_FLOAT */
>>---
>>    
>>
>>>#define FFTW_ENABLE_FLOAT 1
>>>      
>>>
>
>Are you sure about that? Here the fftw configure has generated header
>files prefixed with the 's' when building the library for using
>single-precision floats like this:
>
>$ ./configure --prefix=/usr --enable-float --enable-type-prefix
>$ make clean && make all
># make install
>
>and others without the prefix when issuing
>
>$ ./configure --prefix=/usr [double by default, no type prefix]
>$ make clean && make all
># make install
>
>and four different headers appeared on /usr/include : fftw.h, rfftw.h,
>sfftw.h, and srfftw.h. So I do not think you should have any problem
>with one version clobbering the files of the other version. You can also
>specify the prefix for fftw using doubles, but then the headers get
>named 'dfftw.h' and 'drfftw.h'.
>
>  
>
OK, you are right, my confusion came from the fact that I was comparing
the headers created by configure && make instead of the ones really
copied into system. There is a file fftw/fftw.h that is created during
both builds. It differes as I presented in the diff and it is created
with the name even when --enable-type-prefix is used. But the fact is
that it does not seem to be copied into /usr/include, so everything
should be OK.

>Don't worry about this at all -- CLAM already handles this 'diversity in
>unity' of fftw.
>
>Miguel Ramírez.
>
>
>
>  
>
For now I have installed all the dependencies of CLAM, using many
different ways (compiling myself with shared libraries, using RPMs,
using the compiled version from CLAM website, adding some symlinks,
copying some files manually, something into the sandbox, something into
the system, etc.). Now my system is a little bit of a mess, but the
CLAM's configure gives SUCCESS with all mandatory dependencies and all
users can compile the example shipped with CLAM! So I am quite happy
with what I have.
I am still confused about ".so" files if you say that they should not be
necessary... Do you think that I should work as is, or maybe should try
with CLAM 0.8.0 when it will be out?

By the way when could I expect it? On the website it says a couple of
days...

Greetings,
Rhywek.