But, wouldn't this be a bug in ScummVM's Amiga part then? Or even a bug in the system itself? Or could it be simply that ScummVM's Amiga part is old enough to have outlived the coding necessaties of the current system?
As Salas00 says its bug in public newlib version. For me Barony also crashes with that IDOS 0x00000000 only on public version of os4 , while didn't on beta ones with newer newlib. So while when i test it localy all works fine, when i release it ppls report crashes , and for make it works on public versions i had to do those workarounds.
In other words, made that change localy for your own builds only, without commiting those changes to scummvm repo, as its bug in our side which already fixed just didn't released.
So, i have a bunch of shared objects which i want to strip in one go, preferably with only one command.
I read the manual for strip and tried doing it this way Quote:
strip shareddir/*
which actually seems to work, but it only seems so, as all of the stripped binaries are broken afterwards.
They do have the same size they'd have if i used strip shareddir/sharedlib -o othersubdir/sharedlib, but they are rejected by my program, so i'm assuming something wennt wrong.
My question is: Is strip shareddir/* supposed to work? Might that be a bug in our binutils/strip command? Might it be that on-the-fly stripping/altering of shared libs are not supported or broken?
Is there any other way i could automate the stripping of more than one shared objects WITHIN a makefile?
I know how to do it with "list lformat" and executing the corresponding batch file afterwards, but i'd rather do it in the makefile.
While processing the makefile a temporary file is created in T: and it seems that the for loop holds just the first line instead of the four that needs to be processed.
It errors because the one line does not match a complete loop. Need to find a way to pack everything in one line then.
This one works with "sh test.sh", but will produce empty $p in the makefile script
for p in plugins/*; do "strip $p -o path/$p"; done
Edit: Hmm, something fishy is going on here.
With this line
for _plugin in plugins/*; do "echo $_plugin"; done
i get this output Quote:
for _plugin in plugins/*; do "echo plugin"; done T:gmake.sh.249.ZOLVUI[1]: echo plugin: not found
Why is my variable name cut (missing it's leading underscore) instead of it's entry read out? And who is responsible? I don't think it's the makefile per se, rather the temporary command in T: seem to cut my variable.
Any help appreciated...
Edited by Raziel on 2019/10/21 14:31:15 Edited by Raziel on 2019/10/21 14:32:05
Ok, please help, another one of those darn shared objects bugs i don't know how to deal with...
I get this on starting the app, no window/screen is ever opened, it seems it's crashing while reading in the plugins (again), but this time it's libstdc++ which is complaining
Crash log for task "scummvm"
Generated by GrimReaper 53.19
Crash occured in module libstdc++.so at address 0x7EA176A0
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
I changed the CXXFLAGS from -std=gnu++11 to -std=c++11 and it will error out in configure...that was to be expected, ince vsnprintf is not supported.
I changed it to use none -std and now i'm getting a window on scummvm start telling me
ELF library Unable to resolve symbol '_ZdlPvj' in scummvm
Back to using -std=gnu++11 then and trying your fix
EDIT: I'm editing this, so that i may not forget what the fix was and to help others looking for a solution.
The reason for scummvm failing, was that it overrid --std=gnu++11 with it's configure-based --std=c++11. Since configure will always be the last one claiming compiler flags it clashed.
A fix is now in place as easy as simply using --std=gnu++11 for newlib based, __STRICT_ANSI__ platforms such as AmigaOS4.
C++ backends/platform/sdl/sdl.o backends/platform/sdl/sdl.cpp: In member function 'virtual void OSystem_SDL::initBackend()': backends/platform/sdl/sdl.cpp:295:52: error: cannot convert from pointer to base class 'GraphicsManager' to pointer to derived class 'SdlGraphicsManager' because the base is virtual static_cast<SdlGraphicsManager *>(_graphicsManager)->activateManager(); ^ gmake: *** [backends/platform/sdl/sdl.o] Error 1
edit: i really hope it will be just another NULL pointer case...ideally one that is as easy to fix as the last one
A smaller example would be helpful. I doubt Sebastian will start debugging ScummVM project. Problem is the crash occurs deep in the standard C++ library. There isn't probably any AmigaOS 4 -specific code near that but who knows?
scummvm-test/sobjs/libstdc++.so - is this the one that came with your GCC 8.2 or some other version? Have you checked with Snoopy which .so is loaded?
Does threading model (-athread) make any difference?
I tried to make a trivial dynamic_cast example and was able to crash with an ISI (you have a DSI), when linking dynamically, but I'm simply too tired now to write any kind of "sane" bug report. Maybe on weekend.
No problem, you already gave me some pointers on where to look next.
libstdc++.so is the one that came with my AmigaOS4 install CD, i didn't know there were newer versions...have to take a look.
I also read somewhere about -athread=amiga, which should be used instead of native, have to check that too, i guess.
I'll check out what happens if i explicitely give the plugins path through a DEFINE, instead of letting scummvm find it eventually.
Snoopy doesn't tell me which .so is load, because it will crash beforehand, but the SDL1 build of scummvm tells me that none of the plugins from scummvm can be load, but that might be a completely different error?
GCC:lib/ should have another version. To be honest I don't know how these are to be mixed (the old and new libstdc++.so) and what is the compatibility.
Quote:
Snoopy doesn't tell me which .so is load,
But GR did (show the path). As I said, I'm tired..
I don't think SDL_LoadObject is implemented in SDL1 port.
Hehe, you seem to forget you are talking to noob Mixing is easy, you just have to forget that there is libstdc++.so in yet another directory i completely missed. I was using ancompletely outdated libstdc++ the whole time...funny that it worked at one time. Trying to rebuild and test again...
Thanks for the hint about SDL1 missing SDOL_LoadObject...something for the future in SDL1 port? Should i write a bug report?
Take your time to recover...and thanks for all the hints
Recompiled and rebuilt with updated libgcc and libstdc++ in place and working again
It still crashes, but only if i have an empty .ini. Probably because it can't access some data files which are set up with path= in said .ini file, will have to check that. Why libstdc++ is still crashing is beyond me though, shouldn't have aynthing to do with it...having the correct sobjs/ in place now...ah well, more mysteries.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
