Why are shared library characters not allowed during connection?

Question

This is my second post on this site in my attempt to understand the compilation / linking process with gcc. When I try to make an executable file, the characters must be allowed during the link, but when I try to create a shared library, the characters are not allowed during the link of this library. They may be resolved when I try to make an executable file using this shared library. Practical:

bash$ cat printhello.c #include <stdio.h> //#include "look.h" void PrintHello() { look(); printf("Hello World\n"); } bash$ cat printbye.c #include <stdio.h> //#include "look.h" void PrintBye() { look(); printf("Bye bye\n"); } bash$ cat look.h void look(); bash$ cat look.c #include <stdio.h> void look() { printf("Looking\n"); } bash$ gcc printhello.c printbye.c /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/cck21S0u.o: In function `PrintHello': printhello.c:(.text+0x7): undefined reference to `look' /tmp/ccNWbCnd.o: In function `PrintBye': printbye.c:(.text+0x7): undefined reference to `look' collect2: ld returned 1 exit status bash$ gcc -Wall -shared -o libgreet printhello.c printbye.c printhello.c: In function 'PrintHello': printhello.c:6: warning: implicit declaration of function 'look' printbye.c: In function 'PrintBye': printbye.c:5: warning: implicit declaration of function 'look' 

So my question is why characters are not resolving when I link the shared library. This work (resolving the characters of its downstream stream) should be done when I use this library to create an executable file, but that means we need to know what this library depends on when using this library, but isn't that undesirable?

Thanks Jagrati

Answer 1

Does -z defs what you want when creating the library? If not, check the ld manual pages; there are many options when handling undefined characters.

Answer 2

It doesn't seem like you understand what you asked the compiler driver (gcc) to execute in the first command. Since you did not specify the -c option (only for compilation), you asked gcc to compile the two source files and link them to the standard library (libc) and run at startup (crt0, usually) to make the program work. crt0 tries to enter your program by calling main (), which is an undefined character that the linker cannot find. It cannot find it because you do not have the main () in any of your .c files, right?

So, to your real question: "Why are the symbols of the shared library not allowed during the link?" Answer: what do you mean by "link time"? By default, a dynamically linked program is not “bound” until it is launched (or perhaps not even then, depending on your system).

On Linux, you can see which dynamic libraries are program dependent with the ldd command ("otool -L" is used on Mac OS). At the output of ldd, you will find out which dynamic libraries the program depends on, which is found in the library search path and which of them cannot be found (if any).

When you run a dynamic program, the dynamic linker that was associated with it detects and loads the dynamic libraries that the program depends on, and "fixes" links to external characters. If any of them fails, your program will not start. One of all previously unresolved characters has been resolved, the dynamic linker is returned, and the C runtime will call your main () function. (This is slightly different from Mac OS, but similar in essence, the connection occurs after starting your program.)

Answer 3

I think the -Bsymbolic linker -Bsymbolic is what you are looking for.

Answer 4

A connected person does not have the ability to know, at least in ELF, where are the characters (that is, in which libraries). In OS X, on the other hand, you need to link the libraries as you described. In the end, it is a design matter. One of them is more flexible, the other is more strict.

Answer 5

Even when you create a shared library, it should resolve all dependencies.

Thus, when a shared library is loaded at compile time, it knows which other shared libraries are loaded at runtime so that it can resolve other dependencies.

1) Create a shared library (look. <sharedLib>) with look ()
2) Create a shared library (hg. <sharedLib>) using the hello () bye () link against the look. <sharedLib>
3) Create an application with main () that references hg. <sharedlib>

At runtime, the application will load hg. <sharedlib>, which will load the shared library of the shared library. <sharedlib>

Answer 6

An executable requires an entry point . But a shared library can be built without an entry point, and then the executable can be compiled using this shared library.