Find information about .so

These files are used for a while in Unix systems and was introduced in OS 4.0, with the possibility to use them for programming with the SDK 53.13 released at the beginning of 2009. Technical information related to the implementation in AmigaOS is available at : http://www.friedenhq.org/index.php5?title=Shared_Object_on_AmigaOS_4.0

-use-dynld

It allows to use shared object that will be loaded / linked at runtime. But at compilation time, note that for each path it will check first if a shared object exists, else it will use the static library. So you might think you will use a shared object because you specified -use-dynld but it could not be the case.

-Lpath

This classic option tells to the linker where it has to search the objects. It will look first in the SDK paths.

attempt to open /SDK/newlib/lib/libfreetype.so failed
attempt to open /SDK/newlib/lib/libfreetype.a failed
attempt to open /GCC/lib/gcc/ppc-amigaos/4.2.4/newlib/lib/libfreetype.so failed
attempt to open /GCC/lib/gcc/ppc-amigaos/4.2.4/newlib/lib/libfreetype.a failed
attempt to open /SDK/local/newlib/lib/libfreetype.so failed
attempt to open /SDK/local/newlib/lib/libfreetype.a failed
attempt to open /SDK/local/common/lib/libfreetype.so failed
attempt to open /SDK/local/common/lib/libfreetype.a failed
attempt to open ./libfreetype.so failed
attempt to open ./libfreetype.a failed
attempt to open /SOBJS//libfreetype.so succeeded
-lfreetype (/SOBJS//libfreetype.so)

-lW,-rpath,

This is a linker option and as indicated, it contains a runtime path (see : http://en.wikipedia.org/wiki/Rpath_%28linking%29) that will be hardcoded in the final ELF executable. It is a bad idea to use a SDK related path ! This path "may either override or supplement the system default dynamic linking search path" even if I suppose that the object is search into SOBJS: first on OS4.

Check which shared objects are used

If you compiled "myprogram" and you want to see which dependencies are shared objects, do :

Here is an example of results, you will see used shared objects looking at lines which type is "(NEEDED)" :

 readelf -d example 

Dynamic section at offset 0x5d6c contains 19 entries:
TagType Name/Value
 0x00000001 (NEEDED) Shared library: [libSDL-1.2.so]
 0x00000001 (NEEDED) Shared library: [libfreetype.so]
 0x00000001 (NEEDED) Shared library: [libz.so]
 0x00000001 (NEEDED) Shared library: [libgcc.so]
 0x00000001 (NEEDED) Shared library: [libc.so]
 0x00000004 (HASH) 0x10000e8
 0x00000005 (STRTAB) 0x100051c
 0x00000006 (SYMTAB) 0x100023c
 0x0000000a (STRSZ)617 (bytes)
 0x0000000b (SYMENT) 16 (bytes)
 0x00000015 (DEBUG)0x0
 0x00000003 (PLTGOT) 0x1015e6c
 0x00000002 (PLTRELSZ) 408 (bytes)
 0x00000014 (PLTREL) RELA
 0x00000017 (JMPREL) 0x10007a0
 0x00000007 (RELA) 0x1000788
 0x00000008 (RELASZ) 432 (bytes)
 0x00000009 (RELAENT)12 (bytes)
 0x00000000 (NULL) 0x0

Dependencies

If a shared object it used, its own dependencies must be shared objects too. For example, I tried to test the "libSDL_ttf.so" file I compiled but as the "libfreetype.a" in the SDK subdirectories was found before the "libfreetype.so" in SOBJS: and that can't work ! In that case, prefer the static library (SDL_ttf is small) and create link of the shared object in the path "SDK:Local/newlib/lib" so it will be found at compilation time and "libfreetype.so" will be used, as you specified -use-dynld.

At runtime

We saw that shared objects are stored in SOBJS: (what means SYS:SObjs/) and the ELF loader (elf.library) will look into the path specific with the option -rpath if used. If an object is not found, a window will appear to tell which object is missing and at the end the message "file not an executable" will be printed in a console.

Version number

Create a shared object

It is easy to create a shared object adding the option -fPIC (use uppercase letters !) to compile each file :

Then, to create the shared object, add the option -shared :

Don't forget to add all depending objects like freetype in this case !

Shared objects as plugins

If you are using shared objects as plugins rather than as libraries, then they may require to link against the main executable. In this case you need to add -W,--export-dynamic to the main executable link command (or just --export-dynamic if you are calling ld directly).