3

I have a shared library say libfile2.so (which contains print2() function definition). Now I create a libfile1.so (which contains print1() function definition which in turn calls print2() function in libfile2.so). Now I create a main.c file which contains main() function which calls print1() by dynamically linking libfile1.so.

But I am getting the following error:

./libfile1.so: undefined reference to `print2'**

The following are the commands that I am using:

gcc -c -fpic file1.c gcc -shared -o libfile1.so file1.o gcc -c -fpic file2.c gcc -shared -o libfile2.so file2.o export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH gcc -I. -L. -o main main.c -lfile1
Improve this question
3
  • You should show (a) the command line used to build file1.so and (b) the command line used to build the executable. Both are relevant because you might have built the information that file1.so needs file2.so into file1.so with the answer to (a), and in any case, there are ways to avoid the problem in (b). Note that it is normal for functions in one shared library (e.g. file2.so) to call on functions in another shared library (e.g. libc.so). Or consider libncurses.so which uses libc.so; and so on. Commented Jan 9, 2013 at 11:24
  • I am linking main.c to libfile1.so which contains definition of print1() but print1() calls print2() whose definition is in libfile2.so. Commented Jan 9, 2013 at 12:39
  • You should edit your question to include that information, and you should show the command lines in full. Also, your question discusses file1.so; your comment discusses libfile1.so. There's a lot of difference between the naming conventions. The lib prefix permits the use of -lfile1 notation on the linker command line. Without that prefix, you can't use the shorthand; you must specify the path to the shared object on the link line. There is also mention of dynamic loading in a comment to the answer. That should be part of the question too; it changes things a lot, too. Commented Jan 9, 2013 at 12:47

1 Answer 1

Reset to default
4

If you have called only print1 in your main.c. Then set the path of the libfile2.so in the LD_LIBRARY_PATH. Because it will try to find the dependencies of libfile1.so while linking with main.c.

gcc -o file1.o -c file.c gcc -o file2.o -c file.c gcc -o libfile2.so file2.o -shared gcc -o libfile1.so file1.o -L. -lfile2 -shared gcc -o main.o -c main.c export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH gcc -o main.exe main.o -L. -lfile1

If you have called both print1 and print2 in main.c then link both libfile1.so and libfile2.so like below.

gcc -o main.o -c main.c gcc -o main.exe main.o -L$YOUR_LIB_PATH -lfile1 -lfile2

Because all the symbol used in main.c needs to be resolved while generating executable.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Ok i understand that i need to link both the .so files but why do i get the error that i mentioned in the question if linking happens during run time ?
In main.c I am calling print1() function (which is in libfile1.so) which in turn calls print2() function (which is in libfile2.so). So why should I link both the .so files?. Also the symbols should be resolved at run time right because we are using shared objects (dynamic linking)?
@Sunilbn : In that case no need to link lfile2. Link only lfile1 but before that set the path of lfile2 to LD_LIBRARY_PATH
Yes i have set the path of lfile1 and lfile2 to LD_LIBRARY_PATH but still i am getting the same error. I have one more question why should linking happen while compiling, it should happen during run-time right?
Hey i got it :). We need to link libfile1.so with libfile2.so while creating libfile1.so and then we can link main.c with libfile1.so only. Thanks a lot for the guidance.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.