Shared objects (.so)

Please can somebody alleviate my concerns that the new support for Linux-style .so files will make for lazy programmers.

In the old days, you had to create proper Amiga shared libraries, which was obviously more work, but worked nicely with the system.

Now, I'm not saying that .sos aren't integrated properly (they are, by the looks of things, although should probably be in Libs:SObjs rather than Sys:SObjs), but I can already see some .so files for libraries that have been ported properly as .library for a long time.

Are there any advantages to using the .so versions? Other than making Linux ports quicker? This seems like a bit of duplication when I have, for example, a z.library, libz.so, and a static version in my SDK which is no doubt linked into rather more files than my stick-shaking abilities are capable of.

Should new ports of these libraries be a .library that just opens a .so and forwards the calls? Or should we not bother with the .library wrapper and just call the .so directly? Is it possible to make a wrapper .so that calls a .library?

I'm drifting off the point now, but some information on why this has been done and why it is a Good Thing would be appreciated.

Chris

@Chris

Quote:

The question should be, why would you NOT want it? What is the problem with calling something .so instead of .library?

Python for example, yes, it can be done with an AmigaOS shared library, but at what cost? And when the next version comes out, you need to do a lot of work over again? With this update of elf.library, all I need to do is compiled with -fPIC and link with -shared, and I have a shared version of it.

With every projects, there is always a certain energy required to get you started. If you can lower that starting energy by providing easier access to certain features, then this can only encourage people to do things they would normally not do. If I didn't have dynamic linking, I would have made Python a static binary and not bothered with a shared version, and the Blender binary would be a lot bigger than it is now.

Just look at Edgar's excellent X11 port. Look at the size of individual programs that are statically linked against libX11. Is it possible to make a shared library libX11? Probably, but why go through the hassle?

Finally, take into consideration that shared objects provide different functionality. They have their individual per-context data contrary to AmigaOS libraries that share their data segment. This is sometimes desired, sometimes it isn't. Also, shared objects export symbols by name, and can import symbols by name, from any other shared object (even those loaded during runtime) or the main program. Importing from the main program is something that AmigaOS shared libraries cannot do.

It all boils down to the question of what you want to achieve. shared objects are much easier to use and create. Right now they suffer the drawback that they aren't really shared (they are loaded for each opening program, although a single program will always use only one copy even if e.g. all of them reference libc.so).

About the placement, we are not calling them shared libraries for a reason, and therefore they are not placed in Libs:. Everything in LIBS: should be able to be opened with OpenLibrary. Shared objects aren't.

I hope this clears things up a bit.

@Chris

Quote:

Programmers are always lazy. However, since idltool can generate a ready-to-use library skeleton, I don't really see that much of a difference between creating a shared library vs. creating a shared object.

Quote:

Actually, no. We deliberately call them "shared object", not "shared library", because quite frankly, they are more like object files that are linked at execute time.

Quote:

Why ? Why should someone now convert an existing library to a .so ? And in fact, there are quite a number of advantages for .library files: For example, the shared objects do not allow you to share data between multiple instances (You can, of course, but that requires extra work).

Quote:

They are a tool available to the devloper. Nothing more, nothing less. Some things can be easily ported as a shared object, some things can be better done with shared libraries. It depends on the circumstances. If I were to develop a library for AmigaOS directly, I'd go for a shared library, not a shared objects. Ports are much easier with shared objects simply because they are the way things are done elsewhere.

@tfrieden

I'm very pleased you've implemented shared objects and made them an official part of the OS, giving a specific location for them to reside! Where ports are concerned they will certainly be very beneficial.

I look forward to a future version of X11 which uses shared objects.

Cheers,
Bean.

Nice a very good explanation.. thank you for that

So is it now time for new updates of all the x11 ports? :)

RWO

@Rogue and tfrieden

Thanks for the answers, much clearer now.

Keep up the good work

Chris