Bug 277869 - games/eduke32: build failure for 20240316
Summary: games/eduke32: build failure for 20240316
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-21 15:47 UTC by Ale
Modified: 2024-04-06 09:31 UTC (History)
3 users (show)

See Also:
zirias: maintainer-feedback? (pkubaj)


Attachments
Fix build disabling mimalloc (2.43 KB, patch)
2024-04-03 16:36 UTC, Felix Palmen
no flags Details | Diff
games-eduke32-disable-mimalloc (1.47 KB, patch)
2024-04-05 12:08 UTC, Felix Palmen
zirias: maintainer-approval? (pkubaj)
Details | Diff
games-eduke32-patch-mimalloc-usage (2.18 KB, patch)
2024-04-05 12:10 UTC, Felix Palmen
no flags Details | Diff
games-eduke32-patch-mimalloc-usage (2.18 KB, patch)
2024-04-05 13:47 UTC, Felix Palmen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ale 2024-03-21 15:47:17 UTC
Trying to build the port I'm receiving the following error (on amd64 - 13.3-STABLE):
===>  Building for eduke32-20240316
clang++: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
In file included from source/duke3d/src/anim.cpp:23:
In file included from source/build/include/baselayer.h:10:
In file included from source/build/include/compat.h:481:
In file included from /usr/include/c++/v1/functional:526:
In file included from /usr/include/c++/v1/__functional/boyer_moore_searcher.h:27:
In file included from /usr/include/c++/v1/vector:321:
In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
/usr/include/c++/v1/locale:2822:22: error: no member named 'mi_realloc' in namespace 'std'; did you mean simply 'mi_realloc'?
 2822 |     _Tp* __t = (_Tp*)std::realloc(__owns ? __b.get() : 0, __new_cap);
      |                      ^~~~~
source/mimalloc/include/mimalloc.h:111:40: note: 'mi_realloc' declared here
  111 | mi_decl_nodiscard mi_decl_export void* mi_realloc(void* p, size_t newsize)      mi_attr_noexcept mi_attr_alloc_size(2);
      |                                        ^
1 error generated.
Failed building obj/duke3d/anim.o from source/duke3d/src/anim.cpp!
gmake: *** [GNUmakefile:901: obj/duke3d/anim.o] Error 1
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/games/eduke32
*** Error code 1

Stop.
make: stopped in /usr/ports/games/eduke32


This looks like the same exact error I've reported in bug #277209 about games/NBlood.
Comment 1 Felix Palmen freebsd_committer freebsd_triage 2024-04-03 16:36:06 UTC
Created attachment 249683 [details]
Fix build disabling mimalloc

Here's a patch fixing the build... (The patch actually contains two commits, the first just enables a verbose build log so you can better see what's going on)

It seems to be caused by some problem of the bundled mimalloc allocator with clang17. The patch simply disables using this allocator (I have doubts it makes that much sense not to use our libc's allocator).

Runtime testing pending, have to wait for a huge bulk build of my package repos. If it works fine, I'll ask for maintainer approval ;)
Comment 2 Felix Palmen freebsd_committer freebsd_triage 2024-04-03 16:39:32 UTC
Also adding Piotr, for some reason, bugzilla missed that.
Comment 3 Felix Palmen freebsd_committer freebsd_triage 2024-04-03 16:42:02 UTC
Ah, that's why ... typo in title, fixed :)
Comment 4 Ale 2024-04-03 18:13:10 UTC
(In reply to Felix Palmen from comment #1)
I confirm that your patch fixes the build with clang17 (13.3-STABLE 1303502).
Thank you.
Comment 5 Ale 2024-04-03 18:22:02 UTC
(In reply to Felix Palmen from comment #1)
Applying the same changes to games/NBlood fixes the build also for that port.
bug #277209, comment #4
Comment 6 Felix Palmen freebsd_committer freebsd_triage 2024-04-03 18:27:42 UTC
Interesting! Could you already check whether it also *works* (gameplay)?

I mean, I don't see why not, the patch just avoids using some custom allocator:
https://github.com/microsoft/mimalloc

But still better test it, I'll certainly do soon.

It might also make sense to invest some time checking what actually breaks with mimalloc, maybe report the issue there.
Comment 7 Ale 2024-04-03 18:43:15 UTC
(In reply to Felix Palmen from comment #6)
Sure!
They are both working.
(The annoying thing is that for both saved games are incompatible across updates...)
Comment 8 Ale 2024-04-03 19:24:38 UTC
(In reply to Ale from comment #7)
With both I mean games/eduke32 and games/NBlood.
For each one I tried starting it, playing a little bit, saving the game before quitting and then restarting it and loading the saved game.
Everything looks fine to me...at least as a casual player.

I have to say that for eduke32 some warnings are printed to the console like "Failed including...<.def file here>" and also 2 errors like "File hightile/tile2492.png not found" but that should be totally unrelated and I think are caused by the Pack files used.
Comment 9 Felix Palmen freebsd_committer freebsd_triage 2024-04-05 12:08:32 UTC
Created attachment 249737 [details]
games-eduke32-disable-mimalloc

I finally got around to test it myself, and eduke32 segfaulted... but this wasn't even related to mimalloc, it segfaults when it can't find its game data and I tracked that down to a REINPLACE_CMD adjusting the data.

Now I have three very small changes, so I put them all in a single commit, the attached patch (disabling mimalloc) works for me.
Comment 10 Felix Palmen freebsd_committer freebsd_triage 2024-04-05 12:10:53 UTC
Created attachment 249738 [details]
games-eduke32-patch-mimalloc-usage

As an alternative, here's a patch that keeps using mimalloc. The issue are some #defines to replace malloc() and friends for C code that break the C++ standard headers, so this patch makes sure the header doing this is only included when not compiling C++.

I'm not perfectly sure whether this is correct (if some C++ code uses stdlib's malloc directly, we'd use two different allocators at the same time), but from a quick test, the build result works for me as well.
Comment 11 Ivan Rozhuk 2024-04-05 13:26:49 UTC
(In reply to Felix Palmen from comment #10)
Thanks for fixes.

IMHO better disable custom allocator, it requires less support and I see no disadvantages.
Comment 12 Felix Palmen freebsd_committer freebsd_triage 2024-04-05 13:47:02 UTC
Created attachment 249740 [details]
games-eduke32-patch-mimalloc-usage

Accidentally uploaded the wrong version of the second patch containing a stupid copy&paste error, here's the correct one!

Yes, just disable the custom allocator would be my tendency as well, but let's await Piotr's opinion on that :)
Comment 13 Felix Palmen freebsd_committer freebsd_triage 2024-04-05 18:02:57 UTC
Did some more thorough testing and found the polymer renderer with the latest (2015...) HRP installed keeps "randomly" segfaulting, but I tried with both patches, so I *assume* this isn't related to the allocator. Is this the reason there's no option any more to bundle HRP? It's still offering the overall best gfx quality, although ERP (with polymost renderer) comes somewhat close.

BTW, is it intentional that ERP isn't unzipped (which is needed to use it)? If not, I could experiment a bit more and create another patch for the ERP option :)
Comment 14 Ale 2024-04-06 07:25:17 UTC
(In reply to Felix Palmen from comment #9)
I can't even remember how many years ago I did that, but I guess it was not segfaulting for me because I put an alias on my shell rc file:
alias eduke32='eduke32 -j /usr/local/share/duke3d/"
Comment 15 Piotr Kubaj freebsd_committer freebsd_triage 2024-04-06 09:08:32 UTC
Fixed, thanks!
Comment 16 Ale 2024-04-06 09:29:43 UTC
(In reply to Felix Palmen from comment #9)
I can't even remember how many years ago I did that, but I guess it was not segfaulting for me because I put an alias on my shell rc file:
alias eduke32='eduke32 -j /usr/local/share/duke3d/"
(In reply to Piotr Kubaj from comment #15)
Thanks.
Can you have a look also at bug #277209?
Comment 17 Ale 2024-04-06 09:31:24 UTC
(In reply to Ale from comment #16)
My previous reply to comment #9 has been submitted again, sorry.