I noticed the 3 latest revisions are debug versions only and no changelogs. Is this an oversight or the new direction?
Page 1 of 1
the latest eduke32 revisions
#1 Posted 29 September 2020 - 09:51 AM
#2 Posted 29 September 2020 - 10:22 AM
It means that compilation failed.
Debug builds disable any compiler optimizations, which is why they pass.
Debug builds disable any compiler optimizations, which is why they pass.
#3 Posted 05 October 2020 - 11:17 AM
The source of the issue has been identified, in particular it occurs when compiling for 32 bit with MinGW.
In the meantime, compiling 64 bit non-debug builds locally should still work.
In the meantime, compiling 64 bit non-debug builds locally should still work.
#4 Posted 27 October 2020 - 06:04 AM
OK. I'm still wondering why latest revisions online are still debug versions only and no changelogs.
Just to be clear, I'm not compiling my own. This is from the usual Dukeworld site for synthesis download. So the compiling issue for the whoever does it for that webpage has not been fixed yet?
Just to be clear, I'm not compiling my own. This is from the usual Dukeworld site for synthesis download. So the compiling issue for the whoever does it for that webpage has not been fixed yet?
This post has been edited by Mark: 27 October 2020 - 06:05 AM
#5 Posted 27 October 2020 - 06:07 AM
oasiz, on 29 September 2020 - 10:22 AM, said:
It means that compilation failed.
Debug builds disable any compiler optimizations, which is why they pass.
Debug builds disable any compiler optimizations, which is why they pass.
32bit builds fail compilation so the chain never gets to complete proper.
64bit builds should compile just fine if you want to compile on your own.
#6 Posted 27 October 2020 - 06:43 AM
Mark, on 27 October 2020 - 06:04 AM, said:
So the issue for whoever compiles for that webpage has not been fixed yet?
I'll take oasiz's answer as a "yes"
It doesn't really matter to me. I can still test them in my projects. I was just curious that after a month the synthesis compiles haven't returned to normal.
This post has been edited by Mark: 27 October 2020 - 06:48 AM
#7 Posted 27 October 2020 - 07:07 AM
Sorry, missed that detail..
TX is running the buildbot for syntheiss, the chain is fine and hasn't been changed. Changes to fix some issues in code (I believe it was the fix which prevented the samples/a.m32 from compiling) caused more problems.
Since there are savegame crash fixes, this might be of value to some: https://lerppu.net/mapster.zip 64bit
TX is running the buildbot for syntheiss, the chain is fine and hasn't been changed. Changes to fix some issues in code (I believe it was the fix which prevented the samples/a.m32 from compiling) caused more problems.
Since there are savegame crash fixes, this might be of value to some: https://lerppu.net/mapster.zip 64bit
EDuke32 r9271-83a6addae Built Oct 27 2020 18:04:49, GCC 10.2.0, 64-bit
#8 Posted 27 October 2020 - 10:54 AM
The snapshot I'm using has that shrinker bug which somewhat ruined Fernando's shrinker puzzle in E3L3 (smaller rooms block the ray's passage), also notice that if a goodie drops from a trashcan, and if it's initially blocked (while dropping, ie. another close trashcan), it stops dropping when the other can is destroyed.
#9 Posted 27 October 2020 - 11:10 AM
#10 Posted 27 October 2020 - 12:02 PM
oasiz, on 27 October 2020 - 07:07 AM, said:
Changes to fix some issues in code (I believe it was the fix which prevented the samples/a.m32 from compiling) caused more problems.
This isn't the case. The error started with a compiler upgrade, as the offending code stems from a much older revision (https://voidpoint.io...920729651521f2d) and has worked fine for months before the error started occurring.
In fact, if you were to compile older revisions, the same issue would occur now.
In more technical terms, the error occurs when one tries to set "std::string" as the template argument for the type of both the key and the value in std::unordered_map, and then adds entries to it.
It's possible that we are dealing with a compiler bug, as the code in question doesn't seem to do anything wrong by itself. In fact, even the simple example code from cppreference.com will cause this error to occur.
The Watchtower, on 27 October 2020 - 10:54 AM, said:
The snapshot I'm using has that shrinker bug which somewhat ruined Fernando's shrinker puzzle in E3L3 (smaller rooms block the ray's passage),
I've reported the issue on the gitlab tracker here: https://voidpoint.io...32/-/issues/133
It's not been fixed yet.
Quote
also notice that if a goodie drops from a trashcan, and if it's initially blocked (while dropping, ie. another close trashcan), it stops dropping when the other can is destroyed.
So you mean it keeps hanging in the air?
#11 Posted 27 October 2020 - 12:17 PM
Ah my bad then, thanks for the clarification.
Timing was unfortunate.
Timing was unfortunate.
Share this topic:
Page 1 of 1