Continue to generate various dynamic libraries required by
storm_analys, this time a new error occurred.
fatal error:'fftw3.h' file not found ------->#include <fftw3.h>
A header file is missing. So install it yourself. The FFTW library is a fast Fourier transform library in C language.
Official Installation Guide Install FFTW on MacOS
Step 1. Install the fftw library of C language
Later, Baidu found out that homebrew can install this directly, so I typed the command brew install fftw, part of the output of the installation process is as follows
==> ./configure --prefix=/usr/local/Cellar/open-mpi/4.0.2 --enable-ipv6 --with-libevent=/usr/local/opt/libevent --with-sge ==> make all ==> make check ==> make install 🍺 /usr/local/Cellar/open-mpi/4.0.2: 752 files, 11.2MB, built in 12 minutes 57 seconds ==> Installing fftw ==> ./configure --enable-single --enable-shared --prefix=/usr/local/Cellar/fftw/3.3.8_1 --enable-threads --enable-mpi --enable-openmp - ==> make install ==> make clean ==> ./configure --enable-shared --prefix=/usr/local/Cellar/fftw/3.3.8_1 --enable-threads --enable-mpi --enable-openmp --enable-sse2 --e ==> make install ==> make clean ==> ./configure --enable-long-double --enable-shared --prefix=/usr/local/Cellar/fftw/3.3.8_1 --enable-threads --enable-mpi --enable-ope ==> make install 🍺 /usr/local/Cellar/fftw/3.3.8_1: 73 files, 14.8MB, built in 6 minutes 56 seconds ==> Caveats ==> hwloc Bash completion has been installed to: /usr/local/etc/bash_completion.d
After installation, you can find a series of header files under the default path
/usr/local/include of gcc. You can see the time, I just installed it
ll /usr/local/include | grep fftw lrwxr-xr-x 1 user admin 44 Aug 12 09:53 fftw3-mpi.f03@ -> ../Cellar/fftw/3.3.8_1/include/fftw3-mpi.f03 lrwxr-xr-x 1 user admin 42 Aug 12 09:53 fftw3-mpi.h@ -> ../Cellar/fftw/3.3.8_1/include/fftw3-mpi.h lrwxr-xr-x 1 user admin 38 Aug 12 09:53 fftw3.f@ -> ../Cellar/fftw/3.3.8_1/include/fftw3.f lrwxr-xr-x 1 user admin 40 Aug 12 09:53 fftw3.f03@ -> ../Cellar/fftw/3.3.8_1/include/fftw3.f03 lrwxr-xr-x 1 user admin 38 Aug 12 09:53 fftw3.h@ -> ../Cellar/fftw/3.3.8_1/include/fftw3.h lrwxr-xr-x 1 user admin 45 Aug 12 09:53 fftw3l-mpi.f03@ -> ../Cellar/fftw/3.3.8_1/include/fftw3l-mpi.f03 lrwxr-xr-x 1 user admin 41 Aug 12 09:53 fftw3l.f03@ -> ../Cellar/fftw/3.3.8_1/include/fftw3l.f03 lrwxr-xr-x 1 user admin 41 Aug 12 09:53 fftw3q.f03@ -> ../Cellar/fftw/3.3.8_1/include/fftw3q.f03
As for how this
/usr/local/include is determined, you can use the following command to view the search path of the default library file for gcc
gcc -x c -v -E /dev/null ##Part of the output display contains the default include addressing path #include "..." search starts here: #include <...> search starts here: /usr/local/include /Library/Developer/CommandLineTools/usr/lib/clang/11.0.3/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) End of search list. # 1 "/dev/null"
Step 2. Solve the problem that the header file cannot be associated with the source file
After installing and being able to find the header file, regenerate the dynamic link library. This time it will no longer be prompted that the header file cannot be found, but the previous error has appeared again.
gcc -dynamiclib -o libmatched_filter.dylib matched_filter.c Undefined symbols for architecture x86_64: "_fftw_destroy_plan", referenced from: _cleanup in matched_filter-d9e7cc.o "_fftw_execute", referenced from: _convolve in matched_filter-d9e7cc.o _initialize in matched_filter-d9e7cc.o "_fftw_free", referenced from: _cleanup in matched_filter-d9e7cc.o "_fftw_malloc", referenced from: _initialize in matched_filter-d9e7cc.o "_fftw_plan_dft_c2r_2d", referenced from: _initialize in matched_filter-d9e7cc.o "_fftw_plan_dft_r2c_2d", referenced from: _initialize in matched_filter-d9e7cc.o "_ftmComplexCopyNormalize", referenced from: _initialize in matched_filter-d9e7cc.o "_ftmComplexMultiply", referenced from: _convolve in matched_filter-d9e7cc.o "_ftmDoubleCopy", referenced from: _convolve in matched_filter-d9e7cc.o _convolveMemo in matched_filter-d9e7cc.o _initialize in matched_filter-d9e7cc.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
This time I understand, I must have found the header file, but the source file corresponding to the header file cannot be associated. Because it is installed with homebrew, the installation path may not be in the default addressing path of gcc. Then yesterday's error report about kdtree could not be resolved must be the same reason.
Inquired about the association between C language header files and library functions on the Internet, and got the following information.
Second, how to associate source files with header files
This question actually means that the known header file "ah" declares a series of functions, and these functions are implemented in "b.cpp", so if I want to use these declared in "ah" in "c.cpp" Functions implemented in "b.cpp" usually use #include "ah" in "c.cpp", so how does c.cpp find the implementation in b.cpp?
In fact, there is no direct relationship between .cpp and .h file names, and many compilers can accept other extensions. For example, when I see the source code of Oumen, the .cpp file has been replaced by the .cc file.
In Turbo C, the command line is used to compile. The command line parameters are the name of the file. The default is
.h, but it can also be customized to .xxx and so on.
some boos mentioned that when the compiler preprocesses, the #include command should be "file included processing": copy all the contents of file2.c to #include "file2.c". This also explains why many compilers don't care what the suffix of this file is-because #include preprocessing is to complete a "copy and insert code" work.
When compiling, it will not look for the function implementation in the b.cpp file. This work is done only when linking. We use #include "a.h" in b.cpp or c.cpp to actually introduce related declarations so that the compilation can pass, and the program does not care where the implementation is or how it is implemented. The source file is compiled into an object file (.o or .obj file). In the object file, these functions and variables are treated as symbols. When linking, you need to specify in the makefile which .o or .obj file to be connected (here is the .o or .obj file generated by b.cpp). At this time, the linker will go to this
.obj file Find the functions implemented in b.cpp, and then build them into the executable file specified in the makefile.
So my link process will make mistakes, because the linker can't find where the original file is. Naturally, the function declared in the header file cannot be used.
Using -L and -l to specify the path, there are still errors, but at least some of them are found, and there are a lot less undefined files that report errors.
gcc -L /usr/local/lib -l fftw3 -dynamiclib -o libmatched_filter.dylib matched_filter.c Undefined symbols for architecture x86_64: "_ftmComplexCopyNormalize", referenced from: _initialize in matched_filter-9f6f25.o "_ftmComplexMultiply", referenced from: _convolve in matched_filter-9f6f25.o "_ftmDoubleCopy", referenced from: _convolve in matched_filter-9f6f25.o _convolveMemo in matched_filter-9f6f25.o _initialize in matched_filter-9f6f25.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation #Explaination of parameters -L #Connect the path where the dynamic library is located -l #Connect the name of the dynamic library If the dynamic library file is libxxxx.dylib, then you should enter -l xxxx when setting the parameters