I am compiling a test program to test the fftw3 (ver3.3.4). Since it is not installed with root previlidge the command I used is:
gcc -lm -L/home/my_name/opt/fftw-3.3.4/lib/ -I/home/my_name/opt/fftw-3.3.4/include/ fftwtest.c
where the library is installed in
/home/my_name/opt/fftw-3.3.4/
My code is the 1st tutorial on fftw3's website:
#include <stdio.h>
#include <fftw3.h>
int main(){
int n = 10;
fftw_complex *in, *out;
fftw_plan p;
in = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
out = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
p = fftw_plan_dft_1d(n, in, out, FFTW_FORWARD, FFTW_ESTIMATE);
fftw_execute(p); /* repeat as needed */
fftw_destroy_plan(p);
fftw_free(in); fftw_free(out);
return 0;
}
when I compiled the program it returns me following errors:
/tmp/ccFsDL1n.o: In function `main':
fftwtest.c:(.text+0x1d): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x32): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x56): undefined reference to `fftw_plan_dft_1d'
fftwtest.c:(.text+0x66): undefined reference to `fftw_execute'
fftwtest.c:(.text+0x72): undefined reference to `fftw_destroy_plan'
fftwtest.c:(.text+0x7e): undefined reference to `fftw_free'
fftwtest.c:(.text+0x8a): undefined reference to `fftw_free'
collect2: ld returned 1 exit status
A quick search implies that I am not linking to the library correctly, but interestingly it does not complain about the declaration of fftw_plan and fftw_complex. In fact if I remove all functions starting with "fftw_", keeping only the declaration, it will pass the compilation.
So where did I go wrong? Is the linking correct? Any suggestion would be appreciated.
You have told the linker where to find the library through -L, but you haven't told it which library to link to. The latter you do by adding -lfftw3 at the end of the line, before -lm.
Additionally, the -L flag needs to be listed after fftwtest.c.
You need to also add that you link to the fftw library.
Add something like:
-lfftw
It depends on what the library file is actually called. (Note how you do that for the math library with -lm.)
Related
I was developing an embedded project an was struggling to compile it because of this error:
mipsel-linux-gnu-ld: main.o: in function 'fooBar':main.c:(.text+0x3ec): undefined reference to 'memcpy'
This error is caused by every operation similar to this, in which I assign the value of a pointer to a non-pointer type variable.
int a = 0;
int *ap = &a;
int c = *ap; //this causes the error
Here's another example:
state_t *exceptionState = (unsigned int) 0x0FFFF000;
currentProcess->cpu_state = *exceptionState; //this causes the error
I have already included the flag -nostdlib in the makefile...
Thank you in advance!
I have already included the flag -nostdlib in the makefile...
Take that flag out. It blocks linkage to standard library calls. The compiler might actually generate references to the memcpy function, even if your code doesn't explicitly call it.
If you absolutely need -nostdlib, I suppose you could define your own version of memcpy - if that's the only function the linker is complaining about. It won't be as optimized, but it would work. add the following code to the bottom of one of your source files:
void *memcpy(void *dest, const void *src, size_t n)
{
for (size_t i = 0; i < n; i++)
{
((char*)dest)[i] = ((char*)src)[i];
}
}
The fact that you have included -nostdlib is what's causing your problem.
If you copy a structure the compiler may call the standard C runtime function memcpy() to do it. If you link with -nostdlib then you're telling the linker to not include the standard C runtime library.
If you have to use -nostdlib then you'll have to provide your own implementation of memcpy().
Well, I think my problem is a little bit interesting and I want to understand what's happening on my Ubuntu box.
I compiled and linked the following useless piece of code with gcc -lm -o useless useless.c:
/* File useless.c */
#include <stdio.h>
#include <math.h>
int main()
{
int sample = (int)(0.75 * 32768.0 * sin(2 * 3.14 * 440 * ((float) 1/44100)));
return(0);
}
So far so good. But when I change to this:
/* File useless.c */
#include <stdio.h>
#include <math.h>
int main()
{
int freq = 440;
int sample = (int)(0.75 * 32768.0 * sin(2 * 3.14 * freq * ((float) 1/44100)));
return(0);
}
And I try to compile using the same command line, and gcc responds:
/tmp/cctM0k56.o: In function `main':
ao_example3.c:(.text+0x29): undefined reference to `sin'
collect2: ld returned 1 exit status
And it stops. What is happening? Why can't I compile that way?
I also tried a sudo ldconfig -v without success.
There are two different things going on here.
For the first example, the compiler doesn't generate a call to sin. It sees that the argument is a constant expression, so it replaces the sin(...) call with the result of the expression, and the math library isn't needed. It will work just as well without the -lm. (But you shouldn't count on that; it's not always obvious when the compiler will perform this kind of optimization and when it won't.)
(If you compile with
gcc -S useless.c
and take a look at useless.s, the generated assembly language listing, you can see that there's no call to sin.)
For the second example, you do need the -lm option -- but it needs to be at the end of the command line, or at least after the file (useless.c) that needs it:
gcc -o useless useless.c -lm
or
gcc useless.c -lm -o useless
The linker processes files in order, keeping track of unresolved symbols for each one (sin, referred to by useless.o), and then resolving them as it sees their definitions. If you put the -lm first, there are no unresolved symbols when it processes the math library; by the time it sees the call to sin in useless.o, it's too late.
I am trying to use lessfs and learning how it uses mhash to produce its cryptographic fingerprints, so I am taking a look at mhash to see how it handles the hashing algorithms, so I am trying to run some of the examples provided in the program, but I am running into complications and errors
The Mhash example that I was trying to solve is found here: http://mhash.sourceforge.net/mhash.3.html (or below)
#include <mhash.h>
#include <stdio.h>
int main()
{
char password[] = "Jefe";
int keylen = 4;
char data[] = "what do ya want for nothing?";
int datalen = 28;
MHASH td;
unsigned char *mac;
int j;
td = mhash_hmac_init(MHASH_MD5, password, keylen,
mhash_get_hash_pblock(MHASH_MD5));
mhash(td, data, datalen);
mac = mhash_hmac_end(td);
/*
* The output should be 0x750c783e6ab0b503eaa86e310a5db738
* according to RFC 2104.
*/
printf("0x");
for (j = 0; j < mhash_get_block_size(MHASH_MD5); j++) {
printf("%.2x", mac[j]);
}
printf("\n");
exit(0);
}
But I get the following errors:
mhash.c.text+0x6c): undefined reference to `mhash_get_hash_pblock'
mhash.c.text+0x82): undefined reference to `mhash_hmac_init'
mhash.c.text+0x9c): undefined reference to `mhash'
mhash.c.text+0xa8): undefined reference to `mhash_hmac_end'
mhash.c.text+0xf9): undefined reference to `mhash_get_block_size'
collect2: error: ld returned 1 exit status
This is a linker error — ld is the linker program on Unix systems. The linker is complaining because you're using library functions (mhash_get_hash_pblock, etc.) but you didn't provide a definition for them.
The preprocessor directive #include <mhash.h> declares functions (and types, etc.) from the mhash library. That's good enough to compile your program (produce a .o file) but not to link it (to produce an executable): you also need to define these functions.
Add -lmhash at the end of your compilation command line. This instructs the linker that it can look for functions in the library libmhash.a on its search path; at run time, the functions will be loaded from libmhash.so on the search path. Note that libraries must come on the command line after they're used: the linker builds up a link of required functions, which need to be provided by a subsequent argument.
gcc -o myprogram myprogram.c -lmhash
Hi I am getting below error while compiling a c code using gcc
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
I am trying to import the fftw() function into SystemVerilog. Here is my code
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <math.h>
#include <fftw3.h>
void fftw(double FFT_in[],int size)
{
double *IFFT_out;
int i;
fftw_complex *middle;
fftw_plan fft;
fftw_plan ifft;
middle = (fftw_complex*) fftw_malloc(sizeof(fftw_complex)*size);
IFFT_out = (double *) malloc(size*sizeof(double));
fft = fftw_plan_dft_r2c_1d(size, FFT_in, middle, FFTW_ESTIMATE); //Setup fftw plan for fft (real 1D data)
ifft = fftw_plan_dft_c2r_1d(size, middle, IFFT_out, FFTW_ESTIMATE); //Setup fftw plan for ifft
fftw_execute(fft);
fftw_execute(ifft);
printf("Input: \tFFT_coefficient[i][0] \tFFT_coefficient[i][1] \tRecovered Output:\n");
for(i=0;i<size;i++)
printf("%f\t%f\t\t\t%f\t\t\t%f\n",FFT_in[i],middle[i][0],middle[i][1],IFFT_out[i]/size);
fftw_destroy_plan(fft);
fftw_destroy_plan(ifft);
fftw_free(middle);
free(IFFT_out);
//return IFFT_out;
}
Here is a system Verilog code from where I am trying to call fftw
module top;
import "DPI-C" function void fftw(real FFT_in[0:11], int size);
real j [0:11];
integer i,size;
real FFT_in [0:11];
initial begin
size = 12;
FFT_in[0] = 0.1;
FFT_in[1] = 0.6;
FFT_in[2] = 0.1;
FFT_in[3] = 0.4;
FFT_in[4] = 0.5;
FFT_in[5] = 0.0;
FFT_in[6] = 0.8;
FFT_in[7] = 0.7;
FFT_in[8] = 0.8;
FFT_in[9] = 0.6;
FFT_in[10] = 0.1;
FFT_in[11] = 0.0;
$display("Entering in SystemVerilog Initial Block\n");
#20
fftw(FFT_in,size);
$display("Printing recovered output from system verilog\n");
//for(i=0;i<size;i++)
//$display("%f\t\n",(j[i])/size);
$display("Exiting from SystemVerilog Initial Block");
#5 $finish;
end
endmodule
Here is an irun command to compile both systemverilg and C files
# Compile the SystemVerilog files
fftw_test.sv
-access +rwc
# Generate a header file called _sv_export.h
-dpiheader _sv_export.h
# Delay compilation of fftw_test.c until after elaboration
#-cpost fftw_test_DPI.c -end
-I/home/fftw/local/include -L/home/ss69/fftw/local/lib fftw_test_DPI.c -lfftw3 -lm
# Redirect output of ncsc_run to a log file called ncsc_run.log
-log_ncsc_run ncsc_run.log
while running this command give below error:
building library run.so
ld: /home/fftw/local/lib/libfftw3.a(mapflags.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/homefftw/local/lib/libfftw3.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: * [/home/ss69/DPI/./INCA_libs/irun.lnx8664.12.20.nc/librun.so] Error 1
ncsc_run: *E,TBBLDF: Failed to build test library
/home/DPI/./INCA_libs/irun.lnx8664.12.20.nc/librun.so
irun: *E,CCERR: Error during cc compilation (status 1), exiting.
When I simply try to compile C using gcc with below command:
gcc -g -Wall -Werror -I/home/fftw/local/include -L/home/ss69/fftw/local/lib \
fftw_test_DPI.c -lfftw3 -lm -o fftw_test_DPI
I get this error:
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function _start':
(.text+0x20): undefined reference tomain'
collect2: ld returned 1 exit status
Exactly how are you using the function void fftw(double FFT_in[],int size) from your comments it sounds like you are coding routine that is called as DLL or as part of a static library.
If this is the case then adding main() isn't going to help, at all.
What you have written is ABSOLUTELY 100% OK, if it is to be used as a callable routine.
What you might need to do is compile this routine into a library, even a static lib. is probably ok. If this is the case then consult your GCC documentation on how to create a static or dynamic lib.
Finally, I have written Verilog code myself, so you can also provide any lines or references to Verilog documentation that you have read and whose instructions you are following. I assume that at some point you are invoking Verilog and supplying it with a list of libraries it can/should use. Your lib should be included in that list.
Am including comments from jxh per his request:
To import the function into SystemVerilog, you need to compile your function into a shared object. Then, you would point SystemVerilog at the shared object. (I don't use SystemVerilog, but that is what I gather from its web page.)
gcc -shared -fPIC -g -Wall -Werror \
-I/home/ss69/fftw/local/include -L/home/ss69/fftw/local/lib \
fftw_test_DPI.c -lfftw3 -lm -o libfftw_test_DPI.so
Your are missing #include "svdpi.h" in the fftwc.c file (or maybe you are not showing it because it is in fftwc.h). This include is needed for DPI.
You are compiling a DPI library to be used with a SystemVerilog simulator. Therefore, you do not need a main() method.
I prefer to always compile all DPI methods outside of the SystemVerilog compiler. The include the DPI library to the simulation phase. My flow looks something like the following:
${SVTOOL} -compile -f svfiles.f -dpi_header gen_dpi_header.h
gcc -fPIC -pipe -O2 -c -g \
-I${SVTOOL_PATH}/include -Imy_dpi_dir -I. \
-o fftw_test_DPI.o \
fftw_test_DPI.c
gcc -shared -o libdpi.so \
fftw_test_DPI.o [other object files]
# then call ${SVTOOL} again for simulation with libdpi.so
If you cannot get past the first gcc stage then your issue is clearly on the C side.
I do not have access to the fftw3 library at the moment. I'm wondering your void fftw(double FFT_in[],int size) might be clobbering a library function. Try renaming it void dpi_fftw(double FFT_in[],int size)
You have no main function. Every binary must define main. If it doesn't, you don't have a null region of memory that _start defines in the binary, which means your program can't start!
Add a function:
int main(){
fftw(doubleArgumentsArray, intArgument); //Or whatever function calls this function
return 1; //Needed for C89, C99 will automatically return 1
}
Have found the following tutorial on Dynamic Programming Interface (DPI) :
http://www.doulos.com/knowhow/sysverilog/tutorial/dpi/
Specifically, scroll down to the "Including Foreign Language Code".
It should help with background information about how to construct a C modules for SystemVerilog.
Also, the tutorial has the following import statement:
import "DPI" function void slave_write(input int address, input int data);
This SystemVerilog statement obviously has input defs on the parameters, is this required? Your import does NOT identify input vs. output??
I believe this is an issue with some gcc linkers. I added the following linker flag:
irun ... -Wld,-B/usr/lib/x86_64-linux-gnu
And it fixed the issue.
So there's plenty of information about calling C APIs from within D, but how about the reverse? What do you need to do to write a library in D that works like a normal C shared library? Here's an easy case:
main.c
extern int foo(int x);
void main() {
printf("foo(5)=%d\n",foo(5));
}
foo.d
extern(C)
{
int foo(int x)
{
return x*x;
}
}
Naively trying to build and link these with gcc and dmd just results in linker errors.
Linking with gcc main.o foo.o:
doFoo.o: In function `no symbol':
doFoo.d:(.text+0x7): undefined reference to `_Dmodule_ref'
collect2: ld returned 1 exit status
Linking with dmd main.o foo.o:
/usr/lib64/libphobos2.a(deh2_2eb_525.o): In function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xa): undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x14): undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x1e): undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x46): undefined reference to `_deh_end'
/usr/lib64/libphobos2.a(lifetime.o): In function `_D2rt8lifetime18_sharedStaticCtor9FZv':
src/rt/lifetime.d:(.text._D2rt8lifetime18_sharedStaticCtor9FZv+0x15): undefined reference to `_tlsend'
src/rt/lifetime.d:(.text._D2rt8lifetime18_sharedStaticCtor9FZv+0x29): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread+0x2b): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread+0x36): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread+0x28): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread+0x33): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x26): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x31): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a0_713.o): In function `thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x36): undefined reference to `_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x41): undefined reference to `_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
My answer is about using D static libraries from C.
Yes, this is a bit off topic, but shared libraries for Windows are described in D's documentation (http://www.d-programming-language.org/dll.html) and for Linux are still under construction (http://www.digitalmars.com/d/2.0/changelog.html). Working examples for both systems are attached.
Win32: dmd+dmc works great. Example: test_d_from_c_win32.zip
Linux32: dmd adds some required stuff once it has found D main function, so D's main is needed (tested for dmd2+gcc on Linux32).
It's linkage name is "_Dmain" and it will not be mixed with C's one (real "main").
So one can just add the file dfakemain.d with text void main(){}.
dmd -c dfakemain.d will create dfakemain.o with missing symbols. Link it with your object files and you will be happy. Example: test_d_from_c_linux32.tar.gz
According to a quick glance at the compiler source code, _Dmodule_ref is the linked list of module constructors. To fix the issue, add this to your main.c:
void* _Dmodule_ref;
The program now links and runs fine.
(At least, that's how I think it works.)
If gcc is compiling as C++, the default linkage used for the extern will be C++, not C. Try this instead:
extern "C" int foo(int x);
There does not seem to be anything wrong with your D syntax. There is a paragraph confirming your approach here: http://www.digitalmars.com/d/2.0/interfaceToC.html