How to export symbols from a shared library

Question

I 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 the application ( main() ) resolve the addresses where the library functions are to be executed?

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

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

1. You do not need to export symbols with gcc, as it exports all symbols by default; RVDS may or may not do the same, however. Check your RVDS compiler documentation (try configuring it for 'Relocatable ELF' output?)

2. Shared libraries on Linux must be relocatable, as the base address is determined at runtime. Generating position-independent code is ideal, as it reduces the amount of work needed to relocate the library. If your library is not relocatable it will crash (in other words, don't strip relocation information from your object files before making the dynamic library). Symbols are resolved to addresses at runtime after the base address is selected and internal references are relocated.

3. With static libraries, all symbol resolution, relocation, and assignment of load addresses happens at compile time.

My only guess would be that somehow, the code your compiler is putting out is not relocatable at runtime. It's a mystery to me how that would happen without breaking static libraries as well, though...

If you're generating a static library and shared library directly from RVDS, one option would be to try to convert that static library to a shared library:

gcc -shared -o libfoo.so libfoo.a

If this helps, then RVDS's shared library linker (or its configuration) is likely broken.

Answer 3

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.