ScummVM and AmigaOS4.1 F.E.

@Raziel

Hi

I downloaded scummvm-gl4es-test.lha from your cloud

Unfortunately, I have to say that I don't notice any difference in behavior. Scummvm will start without the ini file present, as before. With the creation of the ini file, scummvm crashes during the next startup with a reference from the stack trace to a plugin file in the plugin folder as before. I also tested with your included ini file, but it was probably hopeless as it contained references to games and paths that do not exist with my setup. See picture. Let me know if I have done something wrong during testing, and if there is something else I should have done.




Scummvm.ini file

@Mr_byte

ok, thanks for the test...back to the drawing board

Can you please do a readelf -d name.plugin? I suspect that some so files needed by that plug-in are not present or the .so version is wrong

@afxgroup

Quote:

This is worth a try, but does not explain why there are no problems here on my machine with the same build.

@Maijestro
Quote:Same scummvm executable, but maybe different shared objects (*.so) installed on your machine used by it.

Unfortunately most AmigaOS 4.x developers still don't understand at all how shared objects work on AmigaOS 4.x.
1. Although it's supported by ramlib/elf.library PROGDIR:Sobjs must never be used for shared objects.
2. All .sos have to be installed in the SOBJS: assign (SYS:Sobjs) instead, and there only have to be regular files in it, never any soft links. If you'd use soft links there you'd get the same .so/.dll hell as on Linux and Windows...
3. OTOH soft links have to be used in the SDK:libs (GCC:lib, etc.) directories for building executables. Just like for the runtime linker (elf.library) it can only work correctly for the executable linker (GCC:ld, vbcc:vlink, etc.) if the -soname was set correctly when building the shared object.
4. All .sos have to be build with a proper -soname, without it it can't work, and it has to include any dependencies:
For example when building a shared object for clib4 instead of the default AmigaOS 4.x newlib C library the .soname has to include something like ".clib4" or "_clib4" in it's file- and -sonames, to make sure the incompatible newlib and clib4 shared objects can't be mixed.

As an user there isn't much you can do, with one exception:
If there is a problem with a shared object (.so) use "readelf libfoobar.so" (maybe additional arguments are required) and if there is no "SONAME" section in it it's broken and has to be fixed.

@joerg

1. I was told the other way round
(progdir:sobjs/, so you don't mess up the os)

2. do that and you'll likely end up soft-locking your workbench/os install, since, see 1., SOBJS: is solely meant for the workbench/os

overwrite a crucial wb/os .so with a newer (or different feature set compiled in) version and you'll see what I mean.

believe me, I tried, a new partition with a new os install was the only solution...never touched SOBJS: again

...


to make it clear...the scummvm build works, for me, for other users and at least one user with the same hw than @mr_byte reports no problems as well

I'm inclined to blame @mr_byte's os install now, there seems to be something interfering from which scummvm suffers

@Mr_byte

could you do me a favour and post startup-sequence, user-startup and wbstartup here?

something is messing up your install

@Raziel









So there is another A1222 user who has tested your latest build like me, and it has worked for him? Has he been a beta tester or has he recently bought the motherboard and used the supplied USB recovery memory stick to set up the system? Thinking if there could be something strange with the prepared setup from the memory stick..?


I am willing to do a complete fresh install/recovery of the OS to troubleshoot...

@Mr_byte

that all looks fine so far

could you try to uncheck x-dock and timeguard?
(just vurious as those are the only two I don't use)

if removing those don't fix it I have to unfortunately say it's some part of the hw or some adapted os component

...

well, I was under the impression @Majestro has an a1222 too, but I think I mixed it up again

...

no need for a reinstall...if it is possible you could try booting into a fresh wb and start scummvm from there

though I doubt it will change anything

@Raziel

Hi, i´m a new Owner of an A1222+, Scummvm runs on my System with
changed newlib.library vom Classic AmigaOS4.1 FE CD. With original newlib.library from A1222+ Recovery USB, it crashes on Start with or without Inifile.

On other people´s don´t do it, other Apps don´t run without problems!!!

@Raziel

Quote:


I tried booting without these. No difference unfortunately.

I also tried booting from the recovery usb stick and starting from there, in case I had managed to mess something up in the system that I wasn't aware of. But no change.

I can try to find a new usb stick, format it and transfer the fresh system from the recovery stick to it and install scummvm to this stick as well. Then boot the machine from this without involving the ssd anywhere in the process. To rule out problems with the SSD disk and sata cable.

Otherwise, I agree that there may be some problems with os components that have been put together for the A1222 edition recovery usb stick or same hardware parts are not compatible with something. Missing FPU and the FPU emulator? But it would be nice if someone else with A1222 could test it out. I think @Majestro has sold his A1222 and tested your latest release with his new X5000


UPDATE: I now see that Amigafreak02 may have found out more, same time I made this post.

@Amigafreak02

So glad you found out newlib.library from the a1222 recovery stick created problems. Then maybe I won't have to do more troubleshooting I also see your warning about changing it, as it caused problems for other software for you. Thumbs up.

@Mr_byte

ah, so it could be newlib.lib...

@Raziel

It looks like it is the case when he says that newlib.library from Classic AmigaOS4.1 FE on his a1222 machine makes Scummvm work and that Scummvm crashes with original one from A1222 recover memory stick. But I understand that other software stops working when he switched.

I can also temporarily try a different version of newlib to see how scummvm reacts on my mahcine if I can get hold of it... And then switch back to the a1222 version of newlib afterwards

@Raziel
Quote:The A1222+ version of newlib.library includes some SPE code (internal functions only, AFAIK not callable by SPE compiled software).
Should be faster than emulated FPU code, maybe with less precision in the SPE math functions compared to the FPU ones but that shouldn't cause crashes.

@Mr_byte
Quote:Except for software requiring the newer version of newlib.library using an older one from another system shouldn't cause problems - it's just slower than a special SPE A1222+ version because the FPU code in the other versions has to be emulated on the A1222+.

@joerg

You are right. Mp3 Play Not possible with Classic newlib.
Videoplay not possible with system freez.

With A1222+ newlib it works with following
Disabled Plugins: efh, myst3, composite, wintermude.
And some other Plugins. Complete list can i write here,
When i back home.

@joerg

its far too long ago that I'd be able to remember, but would a newlib.library, placed inside a libs/ directory, inside the scummvm directory be used proritized before the libs: assign?
or does that only work with sobjs/

because that would be a workaround for a1222 users, place the working library inside scummvm's dir structure and the rest of the system programs grab theirs from libs:

@Raziel

In principle, maybe. But newlib.library is a Kickstart module, so it will already be loaded before something like that is even considered.

Best regards,

Niels

@Raziel
Quote:Additionally to what Nils wrote:
It would be even worse doing that with shared AmigaOS libraries than with sobjs.

If you have a foobar.library in PROGDIR:Libs instead of LIBS: and start a program using it as the first program using this library it may be loaded from POROGDIR:Libs and stays in memory. All other programs using foobar.library started later will use this version instead of the one from LIBS:.
If the program with a POROGDIR:Libs/foobar.library is started after another program using foobar.library the one from LIBS: now in RAM will continue to be used, not the one in PROGDIR:Libs.

I'm not sure if it works that way as I don't remember the order in which ramlib searches for libraries, first in POGDIR:Libs, PROGDIR:, etc. and last in LIBS:, or if LIBS: is used first and PROGDIR:Libs, etc. only if it's not found in LIBS:, but in any case it's not possible to have different versions of a foobar.library in LIBS: and PROGDIR:Libs, some programs would always use the wrong one.

@joerg

ah...the joys of having a resident in ram...bugger