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

  • up
    40%
  • down
    60%
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:
  1. -- where to found all the correct sobjs
  2. -- what version of sobj i can use and how to call it
  3. -- 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:
  1. -- .so support not have versions support
  2. -- 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).

Tags: 

Blog post type: 

Comments

Menthos's picture
Thanks for this blog! Keep them coming! :)
/M.Andersson, Viking Technology
walkero's picture
Surely great article, solving a lot questions I had about shared objects and libraries. If I got it right, you are saying that we better use shared objects only for ported software. Is it right?
@walkero
If I got it right, you are saying that we better use shared objects only for ported software.
Shared Objects are ALSO a really easy way to write a "plug-in" system for your programs. The reason this is not a bad idea is that your .so files will not be shared by other programs, and therefore their downsides (lack of versioning, lack of sharing memory) are never an issue.

Author of the PortablE programming language. I love using Amiga OS4.1 on my X1000 & Sam440 :-D
kas1e's picture
@walkero
Surely great article, solving a lot questions I had about shared objects and libraries. If I got it right, you are saying that we better use shared objects only for ported software. Is it right?
Imho (and the same say Rogue, who add sobjs support to amigaos): its better just use sobjs only when its really necessary. I.e. even for ports better to not use it at all, and better make static versions (we have all the libs in static and shared forms on os4depot). The only reasson to use sobjs, its only when it very-very-very necessary : plugins, and some programs which on 99% need using of sobjs. But games, demos and "little" apps, better to make static. Main point, its not think anymore that .sobjs is something which "very good to use". Its just necessary addon to make some heavy-heavy unix/win32 ports, or apps which want dynamic plugins (blender, firefox, lodepaint, qt and i think that all for moment). Its just some programmers/porters start to think "hey, let's use sobjes everythere", what is wrong. And better just trying to avoid sobjs (while they not have versioning). And even if they will have it some day, still, better keep sobjs for something which really need it. But fast ports (expectually games), does not need sobjes at all, and in static form it give only pluses : fast running, no problems for users where to found sobjes and so on. I think the real missleading which comes as idea to use sobjes just as librarys, its because SDK by default trying to use sobjes, but not static versions. And so, programmers just do not want to bother, they just compile it as it : game start to works, so let's release, and does not matter how boring it will be for users.