Why not ? C++ function names are mangled and after that can be handled as C functions are handled now in amiga shared library.
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?
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. 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.
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.
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.
There's more than just the vtables and even the stuff above to worry about. Templating and RTTI present other interesting problems as does thread concurrency. The latter isn't a problem for amiga libraries but remember the STL was not designed with concurrency in mind. GCC has gotten around this on platforms like linux by using a posix thread model in the compiler. In the end, you wouldn't just be creating the shared library, you'd have to reimplement the entire entire STL it provides as well.
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?
On the other hand, you can take an already tried and tested C++ standard library and statically link it to your application. Which is fine. However, with .so files you can defer that until runtime.