More about why SObjs: isn't a great idea

[Matt_H]

I've just finished solving the OS4 equivalent of an episode of DLL hell. An issue in either DOpus 4.18.22 or elf.library 53.12 attempts to open libbz2.so.1.0, which doesn't exist on a 4.1u2 installation with the latest SDK (there's libbz2.so.1.0.4 instead), resulting in 2 highly uninformative error requesters. I was finally able to track down the culprits with the help of a Snoopy log file. xadmaster.library might be involved as well.

This is what happens when version strings are embedded in filenames and then hardcoded into programs. Too many files to keep track of, and they're easily lost during minor upgrades.

Has anyone else experienced this? Or, has anyone ever experienced anything like this with the traditional .library system?

[Matt_H]

As far as I can tell the only reason they exist is that apparently OS4 coders are incapable of creating amiga shared libraries with per caller library base (and the static data in the library base possize). Or they're just too lazy to do it properly, and decided to take the shortcut by introducing the non-shared libraries.

I think the rationale was for easy quick-n-dirty porting (which I'm also not fond of), but I'm thoroughly baffled as to why these well-established native programs are affected. OS4 xadmaster dates from December 2006, which I thought was before SObjs: was introduced. And I can't see why DOpus would need libbz2.so on its own.

incorporating version numbers into lib names seems to be a bad habit taken over from the systems incapable to provide version information ín another way.

Absolutely agreed. That's not a practice we should be emulating.

Compiling these ported libraries into programs statically would be a cleaner solution.

[Matt_H]

Personally, I dislike static linking, but that's just me. It does make it easier for the end user, but then they always complain about the bloat of statically linked executables and the fact that statically linked application X doesn't support feature X that exists in application Y which happens to have been linked against a newer library

Yeah, in the past I have complained about the bloat of static linking, but as I think about it now, maybe it deserves more consideration. Ease of use for the end user used to be of paramount importance on the Amiga. And a static program is a product of the tools available at the time it was compiled. If the tools improve, recompiling the program to take active advantage of those tools might encourage continued developer involvement.

[Matt_H]

This thus also means that if a security flaw in one of the libs that are linked to a lot of programs, they need to be relinked and redistributed to the user.
I know, mentioning security and Amiga in the same context does currently not make much sense.

greets,
Staf.

True, there is that risk. But I'll argue that we have a) security through obscurity, and b) that TCP/IP through a single system library offers an additional inherent layer of security. For example, look how much trouble we have getting Samba daemons and other servers working properly on home networks, let alone across the web

And if a developer needs to recompile to fix a security hole, maybe they'll also take the time to squash bugs or add new features.

The earlier observation that a pair of identically named .so files implementing different ABIs being a uniquely bad problem seems a little contrived. After all, the existing .library mechanism doesn't prevent this kind of lunacy either. I could create a foo.library that is nothing to do with the existing foo.library and as long as the meta data is acceptable, the OS will happily pass it to clients that wanted the original, only to invoke meaningless vectors and crash.

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.

[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?