Sobjs, AmigaOS and how-to-make non-boring apps.

Introduction

The idea of that small article come after i read Rogue's post on hyperion's blog, about usage of classic amiga librarys and freshly added shared objests support to our os. Article explain pretty clear, what is sobjes, and for what they was added to amigaos4. But that text give just some info to think, like "use sobjs when its need it", and no real rulz which need to follow. So, let's try to point out on few of them, but for first you need to read small article about sobjs on amigaos4:

Article about pluses and minuses of native amiga libs and sobjs implementation

And now lets cover the main rulz:

1. Try to not use sobjes when its not need it !

Realisation of sobjs was added on amigaos4 just in case to help programmers to port heavy apps from unix / win32 world easyly. But its not mean that shared objects as idea are perfect, and have only pluses in compare with classic amiga libs. Yes, .sobjs are pretty helpfull for such apps as for example Blender, LodePaint(they use plugins), QT port (there is no way to import code into an amiga .library, as then subclassing Qt objects with virtual function). But for the plain game-ports, sobjes can give users a bunch of problems, like:

  -- where to found all the correct sobjs
  -- what version of sobj i can use and how to call it 
  -- why we need to worry at all to download anything else, we just want to play in game

Of course its almost the same problems as with plain libs, or, for example, MUI classes, but with some small differences:

 -- .so support not have versions support   
 -- for using of single function from .so, whole .so should be loaded fully 

(That all discussed deeply in those 2 articles on which i point on top, so dig in for more details).

Everything will be sorted out just after you, as programmer, will compile everything statically. Today, harddisk space mean nothing, and worring about 1-2 megabytes which you will save in your binary just make no sense (expectually in compare with all the problems with which user can meet it end if you use sobjs). Better for saving the size just do not forget to make "strip binary" before final release (usually, for big games, strip reduce size much better in compare with sobjs usage).

2. Make everything right !

If you still want by any reassons make a binary with sobjs (or, the app on which you work still want sobjs as plugins), then be sure that you do everything "out of the box". I.e. put all the necessary sobjes to the PROGDIR:sobjs, and be sure that your app in end will get sobjs here, and not from system:sobjs/ or whatever else. Or choice any other directory in PROGDIR:, just be sure that .sobjs will loads from there (but PROGDIR:sobjs are better, just because code not need to worry about path, amigaos will get sobjs by default from it, the same as for PROGDIR:libs).

Its can be pretty bad to release a game, or app, which reles on 10-15 sobjs (all those ogg/vorbis/smpeg/image/mixer and so on) without putting all the correct sobjs to the your distributive, just because you force user to meet with problems. Expectually if that user not gamer or amiga fan, but some magical new customer, who want to run one-two games for tests.

If you still, by any of your reasson force yourself to use only sobjs, and you not want to put them to your ditrib, then make a static binary as well and provide 2 bins : shared and static. Static for everyone who not want any problems, and shared, for anyone who install everything fine, and already know how to avoid all the problems which can happens with sobjs.

3. Its all not that hard !

To make static bins, all what you need, its just add "-static" to the linking line. In end of all, you can just check by the "readelf -d binary" if your final binary have any dynamic sections or not (readelf will just show you how many sobjs want your binary, and if it want it at all).

Other small moment can come when you add "-static" , and still, your binary will have some reles on shared objects: that is because of the SDK default setup : when compiler/linker found .so library in say for example newlib/libs/, then it firstly will use .so , and not .a (for static). So, when you check your binary by readelf, and found, that even now after you add "-static" it have usage of some sobjs : just go to sdk directory, and rename that libary.so to library.so__ or anything else, just to make SDK think that there is no .so, and only .a. And by this way binary in end will be 100% static, and when readelf will agree with it, its time for release :)

Final words

Sure, its all can be pretty obvious for some programmers (expectually for skilled programmers), but lately many users or not so skilled programmers start to make some fast ports, where they not want to change makefiles a bit, or understand how to make their prods better and easy to use, and so, some plain users in end will have problems and start to moaning (what is fully understanable and expected).

It's good that amigaos4 have some more support of different standarts (like .so in our case), and its indeed helpfull for heavy progs, but, in this current form, when .so not have version strings and handler can't handle it, better to be pretty carefull and follow those small and easy rulz (and even when version string will be added to our sobjs realisation, everything in that small article still will be actual, and not only for sobjs, but for .librarys as well).