Compile a C program in Linux using shared library [duplicate] - c

This question already has answers here:
linker tells me it can't resolve symbols, but they're there?
(3 answers)
Closed 7 years ago.
I am trying to compile a simple C program in Linux with a shared library.
I have all together in the same folder the following files:
mymain.c
#include "myclib.h"
int main() {
func();
return 0;
}
myclib.h
void func();
myclib.c
#include <stdio.h>
void func() {
printf("hello world!!!!!!!!!!!!\n");
}
Then I followed these steps:
gcc -c fPIC myclib.c (create memoryaddress independent objectfile)
which produces: myclib.o
gcc -shared -fPIC -o libmyclib.so myclib.o (create shared library)
gcc -c mymain.c (creates an object file out of main.c)
So far so good - then I have the following files ready:
main.o
libmyclib.so
So I try to create a program out of this syntax:
gcc -o program -lmyclib -L. mymain.o
(I guess the prefix lib from libmyclib should be replaced with an l?)
But I get the error message from the gc-compiler:
*mymain.o: In function `main':
mymain.c:(.text+0xa): undefined reference to `func'
collect2: error: ld returned 1 exit status*
I have also tested this syntax:
gcc -o program mymain.c -L -lmyclib -Wl,-rpath,.
Then I get the following error:
/usr/bin/ld: cannot find -lmyclib.so
collect2: error: ld returned 1 exit status
What am I doing wrong in these two implementations?
How do I compile this program to an executable using shared library?

You need to place -l options on the end of linker invocation command line:
gcc -o program -L. mymain.o -lmyclib

Related

ceil() only works for rvalues [duplicate]

This question already has answers here:
Why does the order of '-l' option in gcc matter? [duplicate]
(3 answers)
Closed 3 years ago.
I'm trying to compile this program in ubuntu 18.04, 64 bits:
#include <math.h>
#include <stdio.h>
int main() {
double x = 1.9;
float y = 1.8;
int x2 = ceil(x);
int y2 = ceil(y);
printf("%d, %d\n", x2, y2);
return 0;
}
The gcc command I'm using is:
gcc -std=c99 -lm main.c -o main
And the error I'm obtaining is:
/tmp/ccWL94J9.o: In function `main':
main.c:(.text+0x30): undefined reference to `ceil'
main.c:(.text+0x41): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
Although, if I replace ceil(x) by ceil(1.2) for example, and something similar for ceil(y), I can build and execute the program.
In addition, I have checked that I do have libm.so installed:
bash> find /usr/lib -name "*libm.so*"
/usr/lib/x86_64-linux-gnu/libm.so
What I'm missing?
With the following line, it compiles:
gcc -std=c99 main.c -o main -lm
(putting -lm after -o main)
See https://stackoverflow.com/a/11894098/4030665
With some expressions E, particularly constants, the compiler can evaluate ceil(E) while it is compiling, and it does so if this optimization is not disabled. Then the compiler generates code that uses the result and does not call ceil. When the compiler fails to evaluate ceil(E) during compilation, it generates code that calls ceil.
The switch -lm is an abbreviation for the standard math library. The linker processes input files in the order they appear on the command line. When the linker processes a library, it extracts from the library all object modules that contain a definition for a symbol that is currently needed (referenced but not defined) in the executable file (or other output) it is building.
GCC maintains the order of the various units on its command line. Given -lm main.c, it compiles main.c to product an object module, and then it passes -lm and the object module to the linker in that order. Since the math library is first, when the linker processes it, it has not yet seen any symbols that reference it, and therefore it does not take any modules from the library.
If GCC is instead given main.c -lm, the linker processes the math library after the object module for main. Then, when the linker is processing the math library, it will know that main references ceil, so it will extract from the math library the module that defines ceil.
Thus gcc -std=c99 -lm main.c -o main will work with source code that uses only constants with ceil but will not work with the source code in the example, but gcc -std=c99 main.c -lm -o main will work.

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.

gcc : undefined reference to 'function' [duplicate]

This question already has answers here:
gcc: undefined reference to
(2 answers)
Closed 5 years ago.
I have installed a C library on my computer (Ubuntu) called xx, whose header file is at /usr/local/include/xx/xx.h and the .a file and .so file are in the path /usr/local/lib named libxx.a and libxx.so.
The test file:
#include<xx/xx.h>
#include<stdio.h>
int main(){
printf("Test\n");
call_function_declared_in_the_header_file();
return 0;
}
When I use gcc to compile gcc test.c -o test, I get the following error:
/tmp/ccb7O0eh.o: In function `main':
test.c:(.text+0xa): undefined reference to `call_function_declared_in_the_header_file'
collect2: error: ld returned 1 exit status
I don't know why. I am not good at the C language. So how can I fix it?
you have to link against the library, i.e. if you want to include <math.h> ( libm.so / libm.a ) you have to link against :
gcc program.c -o program -lm where the -lm invokes the linking
see http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html,
https://www.rapidtables.com/code/linux/gcc/gcc-l.html
compiling always involves the compiler and the linker

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.

Creating libraries in C/C++ - ld can't find my library

I'm trying to learn how to create a C/C++ library in a linux environment but I'm having a problem (probably a trivial one) that online tutorials had not helped to solve.
For definiteness let's say I have a foo.c file with the following code:
//file: foo.c
#include <stdio.h>
void hello(void)
{
printf("hello!\n");
}
a foo.h:
//file: foo.h
void hello(void);
and a program that uses the function hello() from foo.c, named prog.c:
//file: prog.c
#include "foo.h"
int main(void)
{
hello();
return 0;
}
The three files are all on the same directory. Then I compiled foo.c with:
gcc -fPIC -c foo.c
and got a foo.o file. Then I used ld to create the library file:
ld -G foo.o -o libfoo.so
But when I try to compile prog.c with:
gcc -o prog prog.c -lfoo
I got an error message:
/usr/bin/ld: cannot find -lfoo
collect2: ld returned 1 exit status
I'm convinced that this is some kind of trivial path problem, but I couldn't find the solution. So my question is really if this procedure above is wrong or if I have to put the libfoo.so file in a special path.
Another question is how this changes if I'm using g++ instead of gcc.
Thanks.
EDIT:
I know I can compile both prog.c and foo.c to prog.o and foo.o an then link them to make an executable. But in my original problem I want to compile foo.c in a way that I can distribute to people who will use my functions in their own programs.
ld doesn't search the current directory by default. If you want it to do this you need to use the -L command line option, so if your library is in the current directory you need to add -L. to the last gcc call. If the library is dynamically linked you also need to add the current directory to the environment variable LD_LIBRARY_PATH (I assume you're on linux).
Of course, if your library is in any other non-standard path you need to use that instead of the current directory.
Try
gcc -o prog prog.c -lfoo -L.
The -L switch adds its argument to the set of paths that ld looks in for library files. The syntax is identical for g++.

Resources