More about why SObjs: isn't a great idea

[xeron]

Also a possibility, but with particularly well-coded programs you can put necessary .library files in PROGDIR: or PROGDIR:Libs instead of SYS:Libs.

Sobjs have the same mechanism, IIRC.

[kolla]

Sobjs have the same mechanism, IIRC.

A mechanism that works better for sobjs than for shared libraries.

[xeron]

A mechanism that works better for sobjs than for shared libraries.

Of course, since you can have two programs using incompatible sobjs at the same time in memory and working.

Also, the "non-sharedness" of sobjs doesn't make them entirely useless, they save hard disk space even if they don't save memory (less useful, i admit), and they also still enable you to install a bugfixed library and not have to recompile all the apps that use it to gain the benefit.

Edit: oh.. and the amiga library system isn't immune to some of these problems, I keep two slightly incompatible versions of bgui.library handy, since I have two apps that work with one but not the other, and I can't run both at the same time.

[Karlos]

Also a possibility, but with particularly well-coded programs you can put necessary .library files in PROGDIR: or PROGDIR:Libs instead of SYS:Libs. Granted, that doesn't make it "shared" anymore, but you can have as many different incarnations of foo.library as you have programs that use it. I think MorphOS checks all these places (and more) for every library it attempts to open - Piru can correct me here. This sort of arrangement for .so files would be an improvement.

That doesn't work. If you load application X which requires progdir:foo.library A and then start application Y which requires libs:foo.library B, application Y isn't going to work. The reason being that the request to open foo.library is going to note that it's already open and return the base pointer to it.

Contrast this to progdir:foo.so versus SObjs:foo.so. If the .so files are searched for in the same PROGDIR: > SOBJS: order, then both applications should run fine, each with it's own private copy of the library.

[ChaosLord]

That doesn't work. If you load application X which requires progdir:foo.library A and then start application Y which requires libs:foo.library B, application Y isn't going to work. The reason being that the request to open foo.library is going to note that it's already open and return the base pointer to it.

Contrast this to progdir:foo.so versus SObjs:foo.so. If the .so files are searched for in the same PROGDIR: > SOBJS: order, then both applications should run fine, each with it's own private copy of the library.

As the author of an OS3.0 "particularly well-coded program"  I am free to include any required library in PRODIR:libs/ under a different name such as ChaosFoo.library.  Then everything is guaranteed to work.

I don't think I am currently doing this but I was forced to do it many years ago because sometimes a library evolves over time and becomes incompatible with different versions of itself.

[Matt_H]

That doesn't work. If you load application X which requires progdir:foo.library A and then start application Y which requires libs:foo.library B, application Y isn't going to work. The reason being that the request to open foo.library is going to note that it's already open and return the base pointer to it.

Contrast this to progdir:foo.so versus SObjs:foo.so. If the .so files are searched for in the same PROGDIR: > SOBJS: order, then both applications should run fine, each with it's own private copy of the library.

Interesting point. I hadn't thought about loading both libraries into memory.

So it looks like keeping shared objects in PROGDIR: instead is a realistic compromise between taking advantage of updated/bugfixed .so files without recompiling, and avoiding version control issues in SObjs:. Is that a fair assessment?

Some issues still outstanding are whether programs can take advantage of updated shared objects if the program in question ties them to a specific version by filename (and if it's possible to not do that), and what to do if PROGDIR: is C: (i.e., for ported command line utilities). Are the latter type of programs stronger candidates for static linking?

[cha05e90]

Edit: oh.. and the amiga library system isn't immune to some of these problems, I keep two slightly incompatible versions of bgui.library handy, since I have two apps that work with one but not the other, and I can't run both at the same time.

Yep, that's true. This is why I have a manually patched "agui.library" (and the corresponding application) and the newer bgui.library here. BTW: I you scan through your SOBJS: you might find some .so's that actually have a proper Amiga version string, which makes it easier for us as users. So it CAN be done - but is not usual at the moment. I guess this is one of the shortcomings that we do not have a proper and updated RKRM/style guide and coding rules.

[bloodline]

I know it's sort of off topic, but have you guys played with Objective-C and its runtime object oriented system? I think it's wonderful to have your classes just like the old Amiga shared library

[Karlos]

I know it's sort of off topic, but have you guys played with Objective-C and its runtime object oriented system? I think it's wonderful to have your classes just like the old Amiga shared library

It's the only inherent feature of Objective-C that I actually like. The rest of it is a dog's dinner

[bloodline]

It's the only inherent feature of Objective-C that I actually like. The rest of it is a dog's dinner

Well, since I now have to use C++ for my microcontroller hobby, I have come tothe conclusion that, for high level App development I much prefer Obj-C... But low-level stuff is without question much better done in C++, objective C really wouldn't make much sense there at all!

[Karlos]

Some issues still outstanding are whether programs can take advantage of updated shared objects if the program in question ties them to a specific version by filename (and if it's possible to not do that), and what to do if PROGDIR: is C: (i.e., for ported command line utilities). Are the latter type of programs stronger candidates for static linking?

You could static link against a library if you only wanted that particular version and no other.

Linux uses a versioned shared object scheme that works, but it does require programmers to observe a few rules. The actual .so file will contain a major and minor version number as part of it's name. Changes to the minor version number are not allowed to change the interface presented by the .so (well, they may be able to add new calls and data but they can't alter or remove any existing ones) , they are for internal changes only (bugfixes etc). Changes to the major version number indicate larger changes to the interface that may not be backwards compatible.

Normally, an application will be linked against a major version. Generally, this is just a symlink to a specific revision to that version. Updates can then come along and add new revisions. If any thing goes wrong with a new revision, rolling back to the previous one is trivial, the symlink is just pointed back at the last good working revision.

If you get a new major version, you still can have your previous one installed and all applications linked against that previous major version will still use it.

Finally, you usually have a simple .so symlink to the most recent major version/revision for applications which aren't supposed to be version sensitive.

It all sounds far more complex than it is, but it does mean you can create schemes with multiple versions/revisions of the same shared library installed that generally satisfies most applications. It used to be a bit of a pain but once a few guidelines were set it all sorted itself out.

I think the problem we have in OS4 right now is more a lack of best-practise when it comes to the creation and distribution of .so files.

[Karlos]

Well, since I now have to use C++ for my microcontroller hobby, I have come tothe conclusion that, for high level App development I much prefer Obj-C... But low-level stuff is without question much better done in C++, objective C really wouldn't make much sense there at all!

Give it time. You will eventually realise, as I did, that it's all, without question, much better done in C++

Seriously though, you're right. C++ was always intended to be a superset of C and not intended to in any way reduce the language's suitability for system level programming, rather it was intended to make it more suitable for large scale application development.

[Fats]

That doesn't work. If you load application X which requires progdir:foo.library A and then start application Y which requires libs:foo.library B, application Y isn't going to work. The reason being that the request to open foo.library is going to note that it's already open and return the base pointer to it.

This is not something inherently connected to .library style libraries but to how the loading/caching is currently implemented in exec.

greets,
Staf.

[Karlos]

This is not something inherently connected to .library style libraries but to how the loading/caching is currently implemented in exec.

That's a given, but it is implemented the way it is implemented. You can't have two slightly different versions of the same .library open concurrently, regardless of where you put them on your HD.