I have a static library which I compiled with gcc without c99 mode. I am trying to link it in compilation using gcc -std=c99. This is giving me an error:
undefined reference to 'functionName'
Here, functionName is function inside the static library.
This is my compilation:
gcc -std=c99 -g -I../ -Llib/ -lmylib test.c ../file1.c ../file2.c -o test
I am using C99 here because my code in test.c #includes header files whose implementation uses C99 standard.
The static library(lib/libmylib.a) in not compiled with c99 standard because it's code uses some libraries which are failing to compile in C99 mode(but compiles without c99 flag).
I also tried changing the order of the -L & -l flags to the end & immediately after gcc -std=c99 but it gave the same 'undefined reference' error.
How do I link these together?
Thank you.
EDIT: The function which I've mentioned as functionName is a pseudonym for setupStacktrace() shown here: http://pastebin.com/2RbEEPaj. It is signature is void setupStacktrace();
The order of the command line arguments matter. The way you have it now, the linker goes through your static libraries, realizes that nothing so far need anything it provides, and throw away everything in it. Do this:
gcc -std=c99 -g -I../ -Llib/ test.c ../file1.c ../file2.c -lmylib -o test
Related
On my personal laptop I enter
gcc -std=gnu99 -lm -lgsl -lgslcblas equal_runtimes.c particle_filters.c solvers.c -o equal_runtimes
in the terminal to compile my C code and have no issues. As far as I know this is because the gsl headers and libraries are on the standard search paths /usr/local/include and /usr/local/lib respectively (https://www.gnu.org/software/gsl/doc/html/usage.html).
However, when I try to compile the same code with the above commands on a system in which the headers/libraries are located in /apps/gsl/2.1/include and /apps/gsl/2.1/lib respectively, I get the warning
warning: implicit declaration of function ‘gsl_blas_dgemv’ [-Wimplicit-function-declaration]
Therefore it seems the compiler is not linking the gsl libraries, as it's assuming gsl_blas_dgemv is my function. To try to fix this I've followed the guidance at the above gnu.org link, for which the best I can come up with is
gcc -L/apps/gsl/2.1/lib -std=gnu99 -lm -lgsl -lgslcblas equal_runtimes.c particle_filters.c solvers.c -o equal_runtimes
but still no success. Is there an issue with the above syntax I'm using or is there something else here that I'm missing?
Following on from #Eric Potpischil's comments, the problem was the wrong header <gsl/gsl_cblas.h> being used for gsl_blas_dgemv instead of the correct <gsl/gsl_blas.h>. This was not an issue on my own system as the blas library would automatically be found by virtue of its location, which was not the case when using the external system.
I wrote a code in C in Ubuntu which checks for balanced brackets in the input given.I compiled it using gcc compiler and I am getting the correct output.This is actually a part of an online course and they are asking me to use the compiler flag
gcc -pipe -O2 -std=c11 filename -lm
I don't think I understand what I am supposed to do so I tried compiling using this flag and my code is not compiling. My question is if my code compiles when I do
gcc filename.c
why isn't it compiling when I do
gcc -pipe -O2 -std=c11 filename -lm
The error message I am getting is :
cc1plus: warning: command line option ‘-std=c11’ is valid for C/ObjC but not for C++
The reason is the file ending. A capital C is interpreted as a C++ file. The solution is to just rename the file like this:
mv filename.C filename.c
My question is if my code compiles when I do gcc filename.C why isn't it compiling when I do gcc -pipe -O2 -std=c11 <filename> -lm
See above. But there are some situations where it would not solve everything. While C11 gives some extensions to previous versions, it's not 100% backwards compatible.
-std=c11 is a correct option
however you need at least gcc 4.7 or higher to have this option
By "<filename>" they mean to substitute in the name of the file you want to compile. Including the literal string "<filename>" will not work.
A function, before being used, needs to be declared either in a included header or otherwise (though not a good practice). The header file describes the functions and variables that may be found in a library or an object file and the compiler can create (as of yet) unreferenced symbols to be resolved later whilst linking.
However, my compiler (gcc based toolchain called esp-open-sdk (xtensa CPU)) continues despite finding no reference to a function in the headers and only in the linking stage does the linker intimate of an `undefined reference to <-function-name->'.
Another strange behaviour is that the compiler says nothing if there is no return statement, and the function is not "void".
My question is: What is causing this behaviour? I think it's unlikely but is it some compiler flag?
My compiler flags are:
CFLAGS = -Os -g -O2 -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH
and the linker flags are:
LDFLAGS = -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static
Probably you use an old version of gcc. Before version 5.x, gcc defaults to a non-standard called "gnu90", which is a non-standard version of the obsolete C90 standard. There is no reason to ever use gnu90 unless you are maintaining some old Linux code. To avoid this, compile with:
-std=c11 -pedantic-errors
-std=c11 meaning you want the compiler to use the current C standard, without involving gnus or other strange animals. -pedantic-errors means that you want it to actually follow the standard and not just pretend to do it.
In order to get the warning for no return from functions, you need to use the option -Wreturn-type, which is included by using -Wall. Always compile with
-Wall -Wextra
Note that "Wall" does not stand for "all warnings", as it leads you to believe. Rather, -Wall means a fistful of warnings and -Wextra means a few warnings more.
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 2 years ago.
Im currently writing a program for a uni asssessment and they have a set line to compile it, so if it doesn't work with that it won't be accepted.
They command they use is
gcc -Wall -ansi -lm program.c -o program.out
My program will not compile that way, and it'll give me a undefined referance error (Referring to my log10 using math.h library)
if i use:
gcc -Wall -ansi program.c -o program.out -lm
it works
What could be my issue?
Im using windows 10 64bit and have windows bash installed and gcc.
This would be explained if your instructors are using gold and you are using GNU ld. These are two linkers, both are part of the GNU project, and both are commonly used with GCC.
If you are using GNU ld, you get the "traditional" behavior:
The order of specifying the -L and -l options, and the order of specifying -l options with respect to pathname operands is significant.
This means that you have to put -lm after any object files and libraries that depend on it.
However, if you are using gold, the -l options may appear first.
If you have gold installed on your system, you can test it yourself.
Here is what I get:
$ gcc -lm program.c
/tmp/ccJmBjmd.o: In function `main':
program.c:(.text+0x15): undefined reference to `sin'
collect2: error: ld returned 1 exit status
But if I use gold, it works fine:
$ gcc -lm program.c -fuse-ld=gold
-lm needs to be at the end of the command, most likely in the first case with the literal the compiler is optimizing out the call to any function and therefore does not need to link against the library. This is called constant folding and for example we can see in the gcc docs on Other Built-in Functions Provided by GCC says:
GCC includes built-in versions of many of the functions in the
standard C library. The versions prefixed with __builtin_ are always
treated as having the same meaning as the C library function even if
you specify the -fno-builtin option. (see C Dialect Options) Many of
these functions are only optimized in certain cases; if they are not
optimized in a particular case, a call to the library function is
emitted.
I'm trying to debug an issue where the wrong version of a function gets called causing a segfault. The code that I'm compiling is machine generated and includes a function called 'times' that does a complex multiply of it's two arguments. This code is compiled to a .o before being linked into a higher level object file.
When run this code segfaults and gdb indicates that it's in glibc's version of 'times' which doesn't even take the same number of arguments. The are no instances of '#include anywhere in this code.
Changing the name of times to times1 resolves the problem. This isn't a long term solution though due to the machine generated nature of the code and manually editing the name of this function all the time is unappealing.
The whole mess compiles cleaning with -Wall so I'm not sure where to look. Any ideas on how to resolve this?
Compile chain:
gcc -Wall -I. -g --shared -o dpd.o -fPIC *.c (mahine generated code here)
gcc -g --std=c99 -c -fpic getData.c -I/usr/local/include -L/usr/local/lib -lmatio -I/usr/local/include/iverilog -I$(MATLAB)
gcc -g -shared -o getData.vpi getData.o $(MATLAB)/dpd.o -lvpi -lmatio -L/usr/local/lib
C only uses the name of a function as an identifier, so any two (exported) functions with the same name will conflict. The normal approch is to prefix all exported names in a library with a unique prefix. The other alternative is to use C++ as "a better C" and simply build your C code using a C++ compiler, making use of C++ name mangling.
So the real answer to this one is to throw -fno-builtin-times to gcc. That avoids the problem neatly with no fuss.
This of course assumes that you can't changes the name of times to something that doesn't conflict with a glibc provided function.