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.
It's already up as PR, but i'll add a note that this behaviour has been fixed in beta and should be removed once this beta has hit the streets.
Thank you very much for the help again
Also thank you to all who contributed
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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.
Thanks a lot
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
for p in plugins/*
do
echo "strip $p -o amigaospath/$p"
done
Now, while the above works perfectly in a shell (within a text file, started with "sh test.sh") it errors out in the makefile with Quote:
for p in plugins/* T:gmake.sh.256.JEHKAK[1]: syntax error: `for' unmatched
and i'm puzzled as to why?
Any pointers?
Thank you
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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.
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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.
Edited by Raziel on 2020/5/31 13:30:29
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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
Any debug prints i should set?
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
Is there anything i could do to corner the problem?
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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?
And finally, i'm sorry, but i'm not able to provide any other testcase than ScummVM.
Thank you
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
libstdc++.so is located in sdk:gcc/lib but libgcc.so is in sdk:gcc/lib/gcc/ppc-amigaos/8.3.0/
Why is that? May it be an incomplete installation? A Problem of the beta-nature of gcc 8.3.0?
Can i savely use it? It's huge...894.549 bytes compared to 56.324 of the one i have now (unstripped maybe)? Can i savely strip it?
Questions...
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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.
Thank you very much
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg