On Fri, 8 Sep 2006, Rupert Wood wrote:
> Hugh Sasse wrote:
>
> > fft_2d_filter.o: In function `fft_2d_forward':
> > fft_2d_filter.c:(.text+0x28): undefined reference to
> > `fftw_plan_dft_r2c_2d'
> > fft_2d_filter.c:(.text+0x3c): undefined reference to `fftw_execute'
> :
> > The first form (.text+0x<something>) I don't recall seeing before,
> > though I've been using gcc since about 1990, and these functions are
> > defined in the headers.
>
> That's the offset in object file section where it's encountering the error,
> analogous to the line number GCC prints when you have a source error.
OK.
>
> You need to check that it's looking for the right things and that they're
> actually available. When you say 'defined in headers' what exactly do you
> mean: that these are inline functions in your header file? Or that you
That I have included the fftw3 headers and the library exists in /usr/local/lib
and that I'm including it in the -l options to GCC, so all the components
would seem to be present. This assumption seems to be confirmed by Sun's
tools producing an executable with essentially the same makefile. But
clearly something is still missing, or GCC would be 'happy'.
> declare the prototypes in the header file but they're in one of the other
> sources or one of the libraries, e.g. libfftw3? You should check that the
> functions are available in the object file or library you think they're
> coming from, e.g. by using nm. (If this was Windows I'd ask about calling
To take one example that shows up, it seems to be:
bash-2.05$ /usr/local/bin/nm libfftw3.a | grep fftw_plan_dft_r2c_2d
000008a0 T dfftw_plan_dft_r2c_2d_
00000860 T dfftw_plan_dft_r2c_2d__
U fftw_plan_dft_r2c_2d
00000000 T fftw_plan_dft_r2c_2d
bash-2.05$
> conventions but I don't think Solaris has any problems with that: however
> you could make sure e.g. that the symbol names consistently do or don't have
> a leading underscore.)
>
> > The second one seems to be a linker problem, since it is complaining
> > about the library file itself. Other programs seem to be working
> > with PNG images correctly, however.
>
> It's complaining that it can't find deflate, which is defined in libz. Link
> order is significant: you must link libz *after* you link libpng since
> libpng depends on it.
Oh, I thought it would have to be first for precisely that reason :-)
Is there something that will help me sort these directives correctly?
(looking up `man tsort`, then lorder,...) Hmm, there seems to be rather
more output than I expected (in /usr/local/lib):
bash-2.05$ ls lib{fftw*,z*,png*} | xargs lorder | tsort |wc
/usr/ccs/bin/nm: libfftw3.la: invalid file type
352 352 3946
bash-2.05$
given:
bash-2.05$ ls -F lib{fftw*,z*,png*}
libfftw3.a libpng.so.2@ libpng10.so.0@
libfftw3.la* libpng.so.2.1.0.15* libpng10.so.0.1.0.15*
libpng.a@ libpng10.a libz.a*
libpng.so@ libpng10.so@
bash-2.05$
Briefly looking at the docs for automake, libtool, and autoconf
suggest that those are not the tools to explore for this purpose.
>
> > LD = /usr/local/bin/ld
>
> I realise this might be because you're playing with different ld versions
> but it's generally a good idea to use gcc as LD too - the compiler driver
Can I use gcc in that way *and* tell it which linker to use?
> will run the linker for you. (Particularly when you're dealing with C++ and
> templates, or when you're creating libraries, though, so it might not be
> significant here.)
Thank you,
Hugh
