There are a few changes in glibc-2.10 that might make your software fail to build with it, please refer to my blog post [1] if you're not sure what the problem is. And no I don't usually provide emerge --info with these bugs because they are caused by glibc-2.10! Thanks, Diego [1] http://blog.flameeyes.eu/2009/05/24/c-libraries-galore
Created attachment 194025 [details] Build log
The first error (visible in the attached log here) was just a single missing const qualifier in Main.cpp, but next you'll hit some assembler problems with the asm labels in TexLoad8b.h. As the upstream of mupen64 appears pretty dead and activity seems to have moved over to mupen64plus fork (and they have made some modifications to the assembler portions as well), I wonder if these old mupen64-packages should be queued to the treecleaners? The "replacing" mupen64plus fork has made it into sunrise just a few weeks ago ( bug #215426 ).
@games: Should we lastrite mupen64 in favour of mupen64plus?
joker, see last comment
I vote yes but it's up to joker.
No response means yes? I've added ~x86 to mupen64plus now, so it should be okay...
Tristan do you feel like doing the last-rites now?
Joker, ping? Suggested p.mask entry # Samuli Suominen <ssuominen@gentoo.org> (30 Dec 2009) # Doesn't compile (#273407) # Crashes (#124767) # Has qt3 deps (#283429) # # Replaced by games-emulation/mupen64plus # # Removal in 30 days games-emulation/mupen64 games-emulation/mupen64-alsasnd games-emulation/mupen64-blight-tr64gl games-emulation/mupen64-blight-uhleaudio games-emulation/mupen64-glide64 games-emulation/mupen64-riceplugin
Masked. O.K's by Joker on IRC.
Sorry, i failed here. Didn't notice the bug. But i'm at least fast at responding in IRC.
*** Bug 301386 has been marked as a duplicate of this bug. ***
History. Replaced by mupen64plus.