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 o

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.

Answer 3

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.