How to export symbols from a shared library

Question

Hello,

I have created a shared library(*.so) using the *.o object code files(C source code) using RVDS compiler on windows Host.

I link this shared object with a application(using gcc for arm target on linux host) and obtain a executable, which on running generates segmentation fault.(I know i have to debug it!)

Instead of creating shared library, if I create a static library with same source files, and then link with the application, and then execute the application it works fine as expected.

So my questions are:-

1.) Do i need to export symbols(functions exported to application) or any other symbols, explicitly, in my source file using some constructs so that it works fine when linked with an application? What is needed and how do i do that?

2.) How does shared library work?, i.e. will the addresses where the functions will be loaded and run, will be given in the library be given when library is created. How does application( main() ) resolve the addresses where the library functions are to be executed?

3.)How does static library work, i.e. how does this address specification and resolving happen in case of static library?

Thank You. -AD

Answer 1

This is how it works on linux:

1) No, you needn't do anything. You can, however, restrict exporting variables with gcc -fvisibility command line argument and explicitly flag exported entries with the visibility attribute.

2) The executable will have a table of all functions it imports (these are all functions with default visibility). The loader/linker will pick an address to load the libraries to and fill this table just before running, the calls to those functions are indirect calls. (Note that this holds for shared objects as well)

3) Static linking is performed on link-time (which is after you compile). The actual addresses are substituted in the assembly, and they are direct calls.

Note: There is the thing called PIC (position independent code). AFAIK, this deals with references to data/functions in the same shared object, so the linker needn't overwrite half of the code of the library when loading the library, in the way that the code doesn't make any absolute references to its own data. You might try to experiment with it.

Answer 2

Do you know anything about the cause of the crash?

One possibility if you are loading the shared library dynamically (e.g. via dlopen()) is that you are assuming that the library loaded OK when it didn't, and then are trying to execute functions via null pointers.