@Raziel
All issues we had with .so its because it is evil on AmigaOS :) And that one side of the problem, another one that no one doing with anything for a long-long time.

@kas1e

No doubt.
I've had my fair share with .so problems.

But I think that, as you mentioned, giving it a bit of love might make it work and draw more people to using it.

I actually like the idea of plugging in parts of the code to reduce binary size.

And with projects like scummvm it would be the ideal solution on our ram limited platform.
e.g. having only the engine in ram that you play a game from, would save a ****load of ram for the rest of the system.

Bug hunting would become far easier as well, as would be fixing them.

Also compile time would get down massively too.

I'll stick with at least compiling the shared version and hope that I'll some day hit a reproducible and fixable bug that will show where the problem lies...and hope for a usable debugger...

@Raziel

I might be very very wrong here, but if I remember correctly shared objects on OS4 aren't shared for real, in the sense that only one instance of the lib exists in memory. Each application will have its own copy. If that's the way it works then you'll actually waste memory instead of saving. The 'dynamic' part comes with a cost, it only makes sense (resource wise) if it's shared for real, otherwise static will be smaller (in RAM) and faster (oh well, not much, but anyway). I guess the feature exists to make porting easier. Static builds also makes it possible for the compiler / linker to throw away things that aren't used and apply optimizations that wouldn't be possible otherwise.

@sTix

ScummVM 2.2.0 is a 63 MB executable. That is more than Odyssey web browser!

@Thematic

Perhaps Raziel could try -Os to optimize for size.

Quote:

- https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

@sTix

Quote:
I believe it is still the case. I doubt the support for shared objects has been touched since it was introduced in the OS.

@Capehill

I can, of course, try that switch, but the problem lies, for now, not in the final binary size (AmigaOS4 can still cope with such exe sizes fine, running them at least) but with linking of such big binaries natively.

With every new engine introduced the binary will grow and on linking stage even more ram is used to produce a static binary.
The fact that, on a system with 2 GB installed, only about 1.6 GB is useable, limits such final binary size to a max of approx. 78-80 MB (for ScummVM at least).

With ScummVM 2.3.git I'm already at 75 MB, so give it another year maximum and it won't link natively anymore.


Unfortunately none of the little helper switches, like saving memory in favour of more write accesses while compiling, -flto etc, doesn't work natively.

Of course I could switch to cross compiling, but then i could also trash my amiga completely and switch to pc/linux.


With the shared build on the other hand I not only would have all third party libs out of the main binary, but also every available and future engine as a plugin, which massively reduces the linking ram usage and binary size (2.3.git is way below 30 MB).

I dont think that shared is as broken, because I was able to compile a working shared version with sources from 2.0.0, after that every build was crashing.
I do believe that there is only something stupidly small preventing a working binary, but due to our lack of a proper debugger I cannot provide the reason.

And no, I wasn't able to rebuild the 2.0.0 shared build, because its nothing in scummvm source, but on the system side.
Where, I dont know.

@Raziel

I guess you have the swap partition?

Have you tried to assign T: to some hard drive directory? This trick used to help me in GCC2 times - but it might be that it doesn't help with the linking process...

One possibility would be to split the ScummVM into multiple parts with different games. Not ideal of course :)

Do you mean the dynamic_cast crash by shared build issue or?

@Raziel

There's some info / discussions here https://lwn.net/Articles/797303/

In short; cross-compiling is the only option for what we consider big projects.

@Capehill

Ram is not filled during compilation, but during linking.

SWAP wouldn't work as I understand it, since I already got 2 GB of ram installed.
Wasn't that option necessary only for those who wanted to reach the 2 GB without having that much physical ram installed?
Everything above that 2 GB, be it physical or SWAP, wouldn't be sddressed/seen/used anyway due to kernel limitations.

Yep, its the dynamic_cast one.

Splitting the exe is last resort, I don't want to do that.

@sTix

Someone else will have to take over then

@raziel
hi it's possible to you to test that : https://github.com/BeWorld2018/scummvm/tree/camd

I edit camd for support MorphOS and i merge MorphOS/AmigaOS4 in same file.

I add RemoveMidiLink/DeleteMidi missing on AmigaOS platform but i dont have it to test if working. I use _USE_INLINE_ to delete IExec..

Thanks you

@beworld

Heh, I was looking for you

Will test your branch when I get back home.

Could you also take a look here please?
https://bugs.scummvm.org/ticket/12012
Do you also get a crash/assertion?

@Raziel
i try to type ingame "Indiana Jones Las Crusade) ALT-X, that quit game, no crash here, ALT-S make screenshot.
Do you need specifc test ? what game and key ?

@beworld

Actually no game needed.

Just load in the launcher, then press ALT+*any key*.

Will crash here everytime, though i haven't tried the latest sources.

@beworld

Compiler errors

@Raziel

Missing include maybe.
Should compile, if its declared as:

extern … func( … );

Before it’s used.

or maybe your not using the namespace its declared.

@razeil
I edit it with BSzili's help but again i can't test on AmigaOS4:

https://github.com/BeWorld2018/scummvm ... md/backends/midi/camd.cpp

@liveforit
My goal is have sames fonctions between MorphOS and AmigaOS4, if is possible

@beworld

Quote:

I have not worked on MorphOS, but basically they have common compatibility in AmigaOS3, but you can’t or should not use AmigaOS3 functions, because newer or better stuff, you should use.

So you hide difference between OS's in macros, or you make wrapper's, and/or dummy functions for missing stuff, and you divide the code up in OS depended and none OS dependent code, and different makefiles. That's how I do it.

@beworld

Seems to be still the same errors

@Raziel
Doesn't forget -D__USE_INLINE__ on command line ? That one need it if you want to use old os3x way of funcitons call without IFACE-> things