Why was SObjs added to OS4?

@afxgroup

Quote:
Another big difference is that releasing incompatible versions has become common practice on Linux & friends while with Amiga shared libraries you (theoretically) have the obligation to be backwards compatible, and you cannot get around it (and you have a builtin versioning system, not based on file name). Agreed, it does not always happen in practice, but your example above it's more likely your bzip.library will be fixed rather than a bzip_v2.library appears.

@centaurz

yes, you will have less problem just because not all developers are sued to create amiga libraries but if i create my own bz2.library and my program will replace another one already present could be a problem except if in your code you specify which version (maybe the exactly version) you want to open.
Now anyone can create more simply the .so and so you have this kind of problem. We should try to release all libraries (plus source code) to sobjs on os4depot.
Of course now the problems are more on the eye, but i remember anyone that you can use your own .so in your progdir: or in your progdir:sobjs. The loader will search first for that version instead of searching into sobjs:

@centaurz Quote:
No, it will be slower... but only a LITTLE slower: Because instead of directly jumping to the function in question, it must first retrieve the address of the function from memory, and that requires an additional memory access.

You probably won't notice such speed difference unless you are repeatedly calling such functions in an inner loop, and even then I think usually it won't be major. But some people dislike OOP (C++) because of similar speed overheads.

@nexus Quote:
Thanks! Interesting read. I think I read it a long time ago, and then forgotten some of it... Some benefits I didn't think of:

* dlopen() sounds handy, as you can have plug-ins (same as Amiga libraries allow).
* I guess allows full access to OOP (C++), unlike Amiga libraries, which is a big bonus in my view (plain C is so limiting).
* Also seems to be easier to create shared objects than Amiga libraries. At least I don't know how to create Amiga libraries using C.

@afxgroup Quote:
One thing OS4 libraries support are different Interfaces, and while I haven't seen that used yet, in theory it is very useful when you want to completely change the interface for your library, while keeping it backwards compatible.

BTW, thanks for pointing out that our SObj version problems are mostly down to bad coders, rather than the SObj system itself. Although SObj does still lack automatic checking of version number, but that might be difficult to do automatically anyway.

@ChrisH

Bad coders or porters? I see "libvorbis.so", "libvorbisfile.so", "libvorbisenc.so", "libogg.so", "libsqlite3.so", "libjpeg.so", "libxml2.so" and "libfreetype.so".

sqlite3 and freetype2 I haven't touched (i.e, not uploaded my own .so to OS4Depot). sqlite3 is new enough, and I just get the feeling libfreetype.so might be used by some programs. I haven't gone and looked what programs I have that use .so. Probably almost nothing except for Timberwolf.

So, back to the first paragraph. All of those libraries, have the soname set with no version, and they all COME WITH OS4.1 Update 2. Should we blame Hyperion for getting us into the habit of not having version numbers in the soname?

I'm in 2 minds whether I keep it consistent, or whether I put version numbers on everything. I had just been leaving it whatever the Makefile makes, but as Chris (not ChrisH) has shown me, that a proper soname with version is set if setting version_type to freebsd-elf in libtool:

http://www.amigans.net/modules/newbb/ ... t_id=57507#forumpost57507
http://www.amigans.net/modules/newbb/ ... t_id=57854#forumpost57854

Perhaps this is something Hyperion Entertainment missed when making their shared objects originally?

I think from now on i'll make sure they all have a soname with the version number, but I don't want anyone to think I was merely being lazy or incompetent when uploading some shared objects to OS4Depot recently, even including libtiff which is currently still in the upload queue at OS4Depot. Most of the time i'm just replacing someone elses earlier version, and trying to keep it all consistent.

Isn't the point of shared objects so that a program can reap the rewards of a newer version? Hence the naming convention for the soname only having the major revision number (i.e libjpeg.so.6 instead of libjpeg.so.6.2) and symlinks to libjpeg.so and libjpeg.so.6.2

In almost all cases, replacing a .so hasn't affected anything, and is backwards compatible mainly because it has same major revision number.

libjpeg is an exception. libpng is also an exception, however that has an appropriate soname with a version number.