Conflicting types for 'fsqrt'

[gen2brain]

In file included from mupen64plus-core/src/r4300/fpu.h:25,
                 from mupen64plus-core/src/r4300/mips_instructions.def:50,
                 from mupen64plus-core/src/r4300/cached_interp.c:165:
/usr/include/bits/mathcalls-narrow.h:36:20: error: conflicting types for 'fsqrt'; have 'float(double)'
   36 | __MATHCALL_NARROW (__MATHCALL_NAME (sqrt), __MATHCALL_REDIR_NAME2 (sqrt), 1);
      |                    ^~~~~~~~~~~~~~~
In file included from mupen64plus-core/src/r4300/recomp.h:49,
                 from mupen64plus-core/src/r4300/cached_interp.h:30,
                 from mupen64plus-core/src/r4300/cached_interp.c:37:
mupen64plus-core/src/r4300/hacktarux_dynarec/assemble.h:1653:20: note: previous definition of 'fsqrt' with type 'void(void)'
 1653 | static INLINE void fsqrt(void)
      |                    ^~~~~
make: *** [Makefile:1056: mupen64plus-core/src/r4300/cached_interp.o] Error 1
make: *** Waiting for unfinished jobs....

This is with glibc-2.41 and gcc-15.1.0.

[RogueScholar]

Yep, I'm getting this, too, also building with GCC 15.1.0 and glibc 2.41 (verbose buildlog). I believe the breaking change in fact goes all the way back to glibc v2.35, released some three and a half years ago already. The fact that builds are only broken on the current Ubuntu development release (25.10 "Questing Quokka"), though, makes it likely that some interaction with GCC 15 bears some of the blame as well, IMO.

The compilation unit that errors out is mupen64plus-core/src/r4300/exception.c, but I think that's merely because it's the first one touched that includes mupen64plus-core/src/r4300/hacktarux_dynarec/assemble.h, and that's where the actual fix will have to take place, down near the bottom of the file.

I'll be damned if I have any clue of what it should be, though; maybe just alias it to the glibc function within a conditional that tests the glibc version? 🤷🏻

parallel-n64/mupen64plus-core/src/r4300/hacktarux_dynarec/assemble.h

Lines 1653 to 1657 in 50d3ddd

	static INLINE void fsqrt(void)
	{
	put8(0xD9);
	put8(0xFA);
	}

---

Observations from a wider perspective

It's been over a year since I had to disable builds for every architecture but armv7-a in the Launchpad PPAs and switch from using GCC 11 to Clang for awhile then backtrack to GCC 10 just to keep that one afloat; builds using GCC v11 and up had become a Gordian knot of insufficient buildfarm resources that I had no choice but to give up on. The absence of any chatter about similar build failures here ultimately led me to conclude that almost no one was building this core from source extemporaneously anymore. This repo as a whole has felt like a ghost town for several years, in any event, and the fact that this core lacks even a barebones page of its own on the Libretro Docs site certainly doesn't inspire confidence, either.

N64 was never my kind of platform…has everybody simply moved over to Mupen64Plus-Next? It sure would be nice to cull some of the cores that the community by-and-large simply doesn't have a use for anymore in order to better focus on the ones they do. Last week I was trying to make sense of the Stella cores and ultimately just threw up my hands with them, again out of a sense that it was impossible to know which cores had a userbase wanting to consume the packages and which ones were malingering and waiting for someone to make the decision that they had outlived their RoI and needed to be taken out of the rotation.

I certainly see it in the download tallies from the Launchpad API. The most popular ~18 cores probably average something like 1,000 downloads/month for each of the LTS releases, while the other ~80 (including this one) see only 100-200 downloads/year across all releases. I'd dearly love to see what the counts from the Buildbot are like.

No need to respond to these musing unless you have a genuine interest in doing so, fixing the bug, of course, is what matters.

[hizzlekizzle]

Re: your musings, most people have moved on to mupen64plus-next for regular gameplay, but ParaLLEl-N64 actually has a pretty active user base via the ParaLLEl-Launcher fork. We would like to upstream their changes at some point, but for now pretty much the only real use for our ParaLLEl-N64 core is, unintuitively, potatoes that need the old Glide/Rice/glN64 plugins to run full speed (or at all).

For Stella, the main core is upstreamed. The 2023 fork is when they started requiring c++20(?), which many of our platforms can't support, and the 2014 fork has significantly higher performance (at the cost of reduced accuracy, of course), since many weaker platforms/handhelds/etc can't run the latest version at full speed.

So, in short: many of the apparently pointless cores still have uses and users, but they are not always reflected in desktop download stats (or even the buildbot, which we don't really have detailed stats for). Whether you want to personally spend time maintaining those cores is your own business, though.

[RogueScholar]

Alright, so if I just halted builds for the ParaLLEl-N64 core package in the PPA, odds of my likeness being burnt in effigy or sold as a voodoo doll are pretty slim? 😜

And re: Stella, when you say the main core is upstreamed, are you saying that the https://git.libretro.com/libretro/stella-upstream repo will build a libretro core shared library if given the appropriate incantation? I saw references to a "RetroN 77" there but had no idea what it was for.

[hizzlekizzle]

Heh, correct. I don't think it will hurt anyone's feelings to drop the ParaLLEl-N64 PPA package.

For Stella, yes, that's our mirror of the actual upstream repo. Building should just be a matter of going into src/os/libretro and calling 'make'.

[gavgav11]

This can be fixed by renaming the conflicting fsqrt with something else like
find -type f -name '*.c' -exec sed -i 's/fsqrt/_f2sqrt/g' {} +
find -type f -name '*.h' -exec sed -i 's/fsqrt/_f2sqrt/g' {} +