Shared library support

[SamuraiCrow]

Add support for true shared libraries in all targets.

[SamuraiCrow]

Per-opener and regular shared-libraries should both be supported as options.

[SamuraiCrow]

Merged with #26

[Hypexed]

I was going to ask what was meant by shared libraries. But see it clarified in a comment. Library bases dynamically produced for each opener are in fact standard but don't tend to be as common. As an example, a bsdsocket.library does this.

This would create more overhead while limiting a custom library base. E does this so as to embed an E environment or E runtime so all E functions can be called as usual. ECX uses the same kind of method.

I agree this should be expanded upon. It's why I avoid using library mode for anything. I tend to create the library from inside a commodity but this cannot be done for a proper library or device file. It would be good if the E runtime didn't use the library base, though I can see why, but instead use some global space reachable as direct address or PC relative for it's own use. In addition, it would be good to save and restore and global registers, with a keyword rather that require some non-portable ASM hacking or custom module. Including be able to reference any local and global pointer by alias such as GLOBALBASE or similar. Also being able to specify register parameters would help. As well as any other options for specific use cases like interrupts.

[SamuraiCrow]

I think a "shared" library differs mainly in startup code from per-opener library. I'm not so sure that the GCC issue will cover this either. Reopening.

[SamuraiCrow]

@Hypexed
Could interfaces be implemented into OS3 and MorphOS using a per-opener library as an interface to a shared library? If possible, issue #15 could be incorporated into the framework. I'll comment farther in #15 about the implementation.