Problem compiling C progtam from command line gcc with math.h - c

I am new to the command line and I am trying to run a C program containing the function log10.
If I give
gcc -o -lm randomVamp random\ vampire.c
I get the error
gcc: error: randomVamp: No such file or directory
but randomVamp is the name I wanted to give to the executable, of course it doesn't exist yet.
If I prompt just
gcc -o -lm random\ vampire.c
then I get the error
/usr/bin/ld: /tmp/ccbWivPU.o: in function `main':
random vampire.c:(.text+0x312): undefined reference to `log10'
collect2: error: ld returned 1 exit status
Anyone knows what's going on?
I don't know if it's relevant, but the program also includes stdlib.h and time.h should I use some flag or link them in some way?

-o means that the next argument is the output file name. Replace -o -lm randomVamp with something like -o randomVamp -lm.
Also, note that -l... have no effect if specified before the .c/.cpp/.o/... files. So, the command could look like this:
gcc -o randomVamp random\ vampire.c -lm

Related

Unable to pass additional flags to gcc through mpicc

I have a C program that uses OpenMPI libraries. I am also using functions from libm and have included math.h in my program. When compiling using mpicc, like so
mpicc -lm program.c -o program.out
compilation succeeds, but linking fails, with ld unable to link libm and the following three lines of error
/usr/bin/ld: /tmp/cct0O5Yv.o: undefined reference to symbol 'log10##GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
From what I understand, mpicc is just a wrapper for gcc whose job is to pass compilation and linking flags to gcc. Why is it not passing -lm to gcc? How do I make it pass additional flags to gcc? I couldn't fine anything in the man pages.
I used --showme:compiler and --showme:linker with mpicc and passed those flags to gcc along with -lm, and it generates the final executable just fine.
It turns out that the order of the command line arguments passed to mpicc matters. In order to make mpicc pass additional flags to gcc, place them before the source file
mpicc -lm program.c -o program.out
Flags placed after the source file will be treated as flags to the wrapper and not the "kernel" (in this case gcc).

/usr/bin/ld: cannot find -lRTU_Module Linux / Shared library C code

I have a problem compiling the following line of code :
gcc -o main.c -ldl -lpthread -lRTU_Module main.o
I have the following error message :
/usr/bin/ld: cannot find -lRTU_Module
collect2: error: ld returned 1 exit status
When i try to find the location of my .so it returns this :
locate libRTU_Module.so
/home/owasys/workspace/AccelTest/libRTU_Module.so
/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib/libRTU_Module.so
/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib/libRTU_Module.so.1.0.11
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.0
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.0.0.0
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.1.0.11
I have red multiple of answer to a similar question but i have not solve my problem.
Thank you.
ld normally scans a default/configured set of dirs, generally wouldn't know about custom stuff like /home/a/b/c
Should be easy enough to fix; does this work?
dir=/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib
gcc -o main.c -ldl -lpthread -lRTU_Module.so main.o -L $dir
May need to tell the runtime link editor to search there as well, eg adding this to gcc cmd-line:
-Wl,-rpath=$dir

Linking 2 object files in c to create an executable

I am having an issue with a makefile for something I am making. My makefile looks like this
bag: main.o bow.o
gcc bow.o main.o -o bag
main.o: main.c bow.h
gcc -Wall -ansi -pedantic main.c -o main.o
bow.o: bow.c bow.h
gcc -Wall -ansi -pedantic -c bow.c -o -bow.o
I also have a header file called "bow.h" that is used in both bow.o and main.o. bow.h consists of 8 function definitions and 2 structs, bow.c contains the 8 functions and NO MAIN file. main.c is suppose to be a minimal main file so it only consists of
#include "bow.h"
When I run my makefile in the Terminal with
make
I get this message
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
makefile:2: recipe for target 'bag' failed
make: *** [bag] Error 1
What exactly does this mean, how is it caused and how can I fix it?
Even a minimal program (executable) needs a point to start. For a C program, this is the main() function. Thus, the linker seeks for that function (more precisely, it links the start-up object where main is an unresolved symbol), does not find it, and issues an error.
Thus, you have to provide a main(). Alternatively, you may not generate an executable but a library.

undefined reference to `explain_read' ...... No such file or directory

I need to include libexplain to my project to do certain job. I install it and add the header libexplain/read.h to my code, so far so good and no error reported by the complier. But when I use the function explain_read() provided by libexplain and build the project it says:
/tmp/cc7NjAw0.o: In function `xl45_read(int, unsigned char*)':
connections.cpp:(.text+0x2f): undefined reference to `explain_read'
collect2: error: ld returned 1 exit status
and the build script is:
#!/bin/bash
echo > ./stdafx.h
g++ -O1 -Wall -o ./local_proxy (*.cpp...here is the source file list) -lz -lpthread -lpcap -L/usr/local/lib
actually when I type
whereis libexplain
in terminal, I get
libexplain: /usr/lib/libexplain.so /usr/lib/libexplain.a /usr/include/libexplain
I do a lot of searches and still have no idea what's going wrong. ):
You need to link your object files with libexplain. You can do it using the -l<library name>, like so:
g++ -O1 -Wall -o ./local_proxy *.cpp -lz -lpthread -lpcap -lexplain -L/usr/local/lib
Note the -lexplain flag. For a library with the a file name like libABC.so, you'd use -lABC to refer to that library. The documentation for link options with GCC can shed more light on it.

Why am I getting a gcc "undefined reference" error trying to create shared objects?

Why am I getting an "undefined reference" error using gcc?
I am trying to create a shared object (.so) that exports one function, "external()". I then try to link against the .so but get "undefined reference 'external'". What am I doing wrong here?
File: external.c
int external() {
return 5;
}
File: program.c
int external();
int main(char** argv, int* argc) {
return external();
}
Commands:
$ gcc -fPIC -c external.c
$ gcc -shared -o libexternal.so external.o
$ gcc -L. -lexternal -o program program.c
/tmp/cc3MmhAE.o: In function `main':
program.c:(.text+0x7): undefined reference to `external'
collect2: ld returned 1 exit status
I can even run nm and see that the .so is defining 'external':
Command:
$ nm libexternal.so | grep external
0000040c T external
What am I missing here?
Recent versions of gcc/ld default to linking with --as-needed.
This means if you write -lexternal before the C file the library will automatically get excluded (the order matters when testing if things are "needed" like this)
You can fix this with either of:
gcc -L. -o program program.c -lexternal
gcc -L. -Wl,--no-as-needed -lexternal -o program program.c
The latter of which passes --no-as-needed to the linker, which would cause the library to still be linked, even if you didn't call external() from it.
Note: -Wl,--no-as-needed isn't applied globally to everything that's linked, it's only applied to things that follow it in the command line order. So -lexternal -Wl,--no-as-needed also wouldn't work. This does mean that you can mix and match behaviours though, for example gcc -L. -Wl,--no-as-needed -lexternal -Wl,--as-needed -o program program.c -lmightneed would always link against external, but only link against mightneed if one or both of program.c/libexternal.so caused it to be needed.

Resources