How is OS4 ?

[Fats]

Not every shared library can be implemented using old style shared libraries. Consider libstdc++.so, for example.

Why not ? C++ function names are mangled and after that can be handled as C functions are handled now in amiga shared library. It's true that no compiler or other tool support exist ATM to do it.
Virtual methods are handled by a vtable and by the class constructor(s). The constructor with mangled name can be part of the shared library.

greets,
Staf.

[Fats]

Maybe this dicussion needs to be moved to a dev related forum.
As I'm one of the contributors to the AROS build system I am very interested in it though.

There's slightly more to C++ linkage than name mangling...
How, using nothing but a jsr style jump table library vector do you propose to enforce exception specifiers, for example? If a virtual function in your application throws an exception from within a library call (perfectly possible under the current libstdc++), is the amigaos shared library implementation expected to unwind the stack and properly invoke destructors for everything?

Isn't this problem orthogonal to linking ? Isn't it compile time and C++ ABI related ?
Of course you need to define a C++ ABI and you can't mix different ABIs in one program be they in static link libs, .so or .library files.

I'm not saying it's impossible to achieve but in the end, your library would likely end up deviating from amigaos shared library norms in order to offer the required features expected of the C++ standard library.

What is your definition of the norm. To me a .library has to following norm.
It has a Resident structure that points to the lib init code.
The init code adds the lib to the system list of libs.
The member of this list has a pointer to an LVO table.
3 slots have predefined meaning (OpenLib, CloseLib, ExpungeLib) and have to obey a certain calling convention.

And if you are going to deviate from the norm, then why bother? Static linking has no such problem. And really, that's all .so files do, except actual linking is deferred until runtime.

That the linking is not deferred to runtime is the reason I am a big proponent of amiga style shared libraries.

It's true that no compiler or other tool support exist ATM to do it.

This answers your own question and it's unlikely to change as long as gcc remains the compiler of choice.

It eventually will change (if I live long enough )

There's more than just the vtables and even the stuff above to worry about. Templating and RTTI present other interesting problems.

Again are these not part of the C++ ABI and orthogonal to the linking step. I have to admit that the intimate knowledge of the inside of C++ compilers is when the STL was still developed by SGI. I haven't seen anything at that time with templating that would make it incompatible with amiga shared libraries. I don't know how RTTI is implemented internally so I can't comment on that.

What I in the end envision is that for each shared library you would get two files; for example for libstdc++: libstdc++.a and libstdc++.library. Only the .a file would not contain any real code but stub code to call the right LVO in the .library but for the compiler/linker it would obey all ABI conventions.

So, for your suggestion to work, you need to first build a new compiler and then implement your own complete runtime and STL for it.

It isn't exactly a cakewalk. Who is going to bother?

I'm already doing the C library in the ABI V1 branch of AROS. So C++ and the STL will be a minor things once I come to it

greets,
Staf.

[Fats]

It's different to libraries in that you can have multiple concurrent versions/revisions of the library. The AmigaOS method of opening libraries is based on passing the name and a version, where the version is stored in the library itself. You'll always get at least the version asked for (or failure to open otherwise), but possibly a newer one. You can't have V30 and V40 graphics.library available concurrently, for example. OTOH, with .so libraries, I can have libmystuff.2 and libmystuff.1 and applications that depend on each major version can happily coexist.

With amiga shared libraries you can also achieve these things in the same .library. You can move a function that is incompatible to a new LVO number and keep an old compatible function at the old location. Programs compiled for the old version will get the right behaviour. Programs compiled with the new version will use the new function.

Another trick, that deviates more from the current norm is that you could return a different library base when the lib is opened with version 3 than opened with version 2 or 1.

Now, you may say (and FWIW, I'd generally agree) that in reality, no newer version of a library should break what an older version does and thus being able to support concurrent versions shouldn't be needed. However, you know as well as I do, that in practise, that often isn't how it pans out.

Yes, and that problem is not solved with the numbering, it is only helpful when people realise they make a backwards incompatible change. All the .2 versions of a library still has to be backwards compatible with the previous ones; some programs may even depend on some undocumented behavior. This is what oftentimes causes dependency hell.
 

Personally I think the biggest objection to .so files in OS4 are mostly aesthetic in the "Not Invented Here" sense. They are seen as an alien system that has been incorporated into the OS. I actually think that's rather silly seeing as we all decided long ago that ELF was a sensible format and gcc was to be our preferred compiler system. Shared objects are simply something useful that you can readily use from that combination, so why not?

Not for me. The fact that there is no runtime linking needed for amiga shared libraries is the reason for me to like it.
One of the comments on current AROS is that it is so responsive even on old hardware. One of the reasons for that is that you don't need runtime linking or virtual memory tricks like copy-on-write to be able to support shared libraries.

Side remark: ELF is used in AROS for .library files. There was a time I was also opposed to the ELF format until it was shown to me that you could keep binary executable files still relocatable and it doesn't force you to use virtual memory.

greets,
Staf.