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().
Related
I have llvm compiler that supports Riscv vector intrinsic coding and a core on FPGA that is RV32IMV... I have written a C code for the core but when I compile it I get the following error:
error: undefined symbol: __udivdi3
I think it is because I don't have the necessary library added to my linker file for this purpose
but after I searched for the error I found this:
Undefined reference to '__divdi3'
At the end of this post, the author says:
Alternatively, you could write your own implementations of those
functions, or crib the source from GCC, but I don't see why you would
prefer either of those options.
Can anyone suggest a piece of code that implements this function so that I can add it to my code?
I have already added this pices of code for memcpy and it works fine:
void* memcpy(void* dest, const void* src, size_t n)
{
for (size_t i = 0; i < n; i++)
{
((char*)dest)[i] = ((char*)src)[i];
}
}
I'm trying to compile a large project (https://github.com/ESCOMP/CTSM). I would like to compile it as-is, without editing the code, if possible (it is known to build successfully on many platforms).
I'm using gcc (SUSE Linux) 11.2.1. and I get
In function ncmp : /run/media/dominic/hdbtrfs/dominic/git/ESCOMP/CTSM/cime/src/share/timing/gptl.c:4069:1: error: control reaches end of non-void function [-Werror=return-type]
from the following function. I believe that earlier versions of gcc only gives a warning rather than an error in this instance.
/*
** ncmp: compares values of memory adresses pointed to by a pointer. for use with qsort
*/
static int ncmp( const void *pa, const void *pb )
{
static const char *thisfunc = "GPTLsetoption";
const char** x = (const char**)pa;
const char** y = (const char**)pb;
if( *x > *y )
return 1;
if( *x < *y )
return -1;
if( *x == *y )
GPTLerror("%s: shared memory address between timers\n", thisfunc);
}
I expect this can be fixed by inserting a spurious return statement at the end of the function, but since I am interested to try to build an unmodified version of the code (I'm not currently a contributor on the project, so can't push changes upstream) I'm wondering if there's a workaround to convert this error to a warning using compiler flags?
As requested here is the gcc call that is genertaed by the makefile:
mpicc -c -I/run/media/dominic/hdbtrfs/dominic/git/ESCOMP
/CTSM/cime/src/share/timing -std=gnu99 -O -DCESMCOUPLED
-DFORTRANUNDERSCORE -DNO_R16 -DCPRGNU -DCESMCOUPLED
-DFORTRANUNDERSCORE -DNO_R16 -DCPRGNU -DNUOPC_INTERFACE
-DHAVE_MPI /run/media/dominic/hdbtrfs/dominic/git/ESCOMP
/CTSM/cime/src/share/timing/gptl.c
I'm wondering if there's a workaround to convert this error to a warning using compiler flags?
I would expect the -Wno-error option to have that effect. It should also be possible to narrow the scope of that to the specific diagnostic you report, but beware: there is no way with command-line options alone to narrow the effect to this particular instance of the issue.
Addendum
The question having been edited to show that the diagnostic category is return-type, I can say that one would use -Wno-error=return-type to make all diagnostics of this type warnings instead of errors.
-Werror elevates all warnings to errors. You can turn reverse this for specific warnings with -Wno-error=WarningName, such as -Wno-error=return-type, as is clearly documented in the GCC documentation for warning options:
This switch [-Werror=] takes a negative form, to be used to negate -Werror for specific warnings; for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect.
I have a problem described in the title. I have an Edify language parser that runs without errors when I building it on arm but fails when I try to use it with x86. I traced segfault to yy_scan_bytes function, more precisely to this code:
YY_BUFFER_STATE yy_scan_bytes (yyconst char * yybytes, int _yybytes_len ) {
YY_BUFFER_STATE b;
char * buf;
yy_size_t n;
int i;
/* Get memory for full buffer, including space for trailing EOB's. */
n = _yybytes_len + 2;
buf = (char *) yyalloc(n );
if ( ! buf ) {
YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" );
}
for ( i = 0; i < _yybytes_len; ++i ) {
buf[i] = yybytes[i]; // <==========
}
The full code is here: https://github.com/twaik/edify_x86_failing_code
I've got it from AROMA Installer source.
That's everything I discovered after debug. Thanks.
Trying to build your code gives me these errors:
main.c: In function ‘parse_string’:
main.c:27:5: warning: implicit declaration of function ‘yy_switch_to_buffer’ [-W
implicit-function-declaration]
yy_switch_to_buffer(yy_scan_string(str));
^~~~~~~~~~~~~~~~~~~
main.c:27:25: warning: implicit declaration of function ‘yy_scan_string’ [-Wimplicit-function-declaration]
yy_switch_to_buffer(yy_scan_string(str));
That means that the compiler assumes that yy_switch_to_buffer() and yy_scan_string() return an int, as it does for all functions that are not declared before use (as per the c89 standard). But that is not the case (the first returns void, and the second a pointer (YY_BUFFER_STATE)). Notice that on x86_64, the size of a pointer is not the same as the size of an int.
Adding some band-aid prototypes like
void yy_switch_to_buffer(void*);
void *yy_scan_string(const char*);
to main.c, before their use in parse_string() may stop the segfaulting.
A better fix would be to arrange in the Makefile that the lexer be run with the --header-file=lex-header.h option, and then include lex-header.h from main.c. Or even better, wrap all lex-specific code in some simple functions, and put the prototypes of those functions in a header included from both main.c and the *.l file.
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.)
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