[CLAM] fftw and configure

Miguel Ramírez Jávega mramirez at iua.upf.es
Tue Jul 5 08:57:08 PDT 2005


> 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'
+0x3b):/home/mramirez/Sandboxes/CLAM/build/conftest.cc:29: undefined
reference to `rfftw_create_plan'
+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

$ 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

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

Don't worry about this at all -- CLAM already handles this 'diversity in
unity' of fftw.

Miguel Ramírez.

More information about the clam-users mailing list