Cant build on mac

[SpiceyWolf]

Ive tried following the instructions included in the tools folder (The stuff on various websites seem to be extremely dated) and I cannot seem to get this thing to build and I've tried to look for any answers related to alt build systems or configs, editing the make file and trying to monkeypatch the actual source -> The mupen64plus-core at minimum is 1 component I cannot get to build. It throws an error about cmath header not being found, and I've also tried setting that to math.h but it just goes down a rabbit hole of even more libraries that arent found. On the releases page a binary exists that runs (from the console-frontend) and a brew package that runs, so I don't feel like mupen dropped mac support. Is there any advice or undocumented steps that are required to make this thing build?

Im working on a modding tool that uses a C# frontend for mupen on the different platforms so 'just use the existing build' is off the table if anyone was wondering. I actually dropped 200$ on a imac just to try and support mac users with the frontend ;~;

[Jj0YzL5nvJ]

Take this as example...

[SpiceyWolf]

Oof... even using the build script on github STILL makes the same complaint lmao

[SpiceyWolf]

it exclusively errors for the core in the oglft.h file (subprojects) if that is useful info... Doesn't look like something im going to be able to get past unless i can swap everything manually to something not borked.

[Jj0YzL5nvJ]

I assuming you don't understand the "issue"... Darwin is macOS.

https://github.com/loganmc10/m64p/blob/master/build.sh#L5-L27

Try adding:

export CXXFLAGS='-stdlib=libc++'
export LDFLAGS='-mmacosx-version-min=10.7'
export OPTFLAGS="-O2"

If that fail, add:

export OSD=0 
export NO_ASM=1

See: https://gist.github.com/Jj0YzL5nvJ/5242753837eed35768e61c240f572ecd

[SpiceyWolf]

Oof... Now it just complains the deployment target is invalid and requires osx 10.7 (despite it clearly being listed in the ldflags export)

[SpiceyWolf]

Note i tried doing a command as well i found on the net export MACOSX_DEPLOYMENT_TARGET=10.7 and it made no difference....

EDIT:
Rip, found some lines in the make file setting the version to 10.6... changed those and it finally got passed that. Now to solve nasm :P

SUCCESS!!

[Jj0YzL5nvJ]

It seems like macOS users didn't pay attention to this project for a looooooong time. I'm starting to think that m64p has been successfully compiled thanks to the entropy in the flags at compilation time and not because of its correct implementation.

Take a look at this mess (old to new?):
video-arachnoid
rsp-z64
video-z64
video-glide64
rsp-hle
ui-console
rsp-cxd4
video-rice
input-sdl
audio-sdl
core
video-glide64mk2

General sanitation is necessary, any volunteers?

@loganmc10, @joeldenning

[joeldenning]

I only develop m64p on OSX and it works well for me. It got a bit trickier when i upgraded to big sur (I had to create a symlink manually to get it to use xcode properly), but it still works.

The way that I've worked on mupen64plus-core so far is to make my modifications within m64p and then bring them over to mupen64plus-core after I see them working. So I haven't attempted development of mupen64plus-core directly.

I'm happy to help you through the process, if I can. The main things I know of that are needed are the brew dependencies listed at https://github.com/loganmc10/m64p#m64p. Some of the dependencies in that list, including Qt, are not needed for mupen64plus-core. But SDL and a few of the others are definitely needed.

[Jj0YzL5nvJ]

Welcome to "upstream":
https://github.com/loganmc10/m64p/blob/4b2b64b72285dd68463d7deff45aee436b742606/mupen64plus-audio-sdl2/projects/unix/Makefile#L121
https://github.com/loganmc10/m64p/blob/4b2b64b72285dd68463d7deff45aee436b742606/mupen64plus-core/projects/unix/Makefile#L202
https://github.com/loganmc10/m64p/blob/4b2b64b72285dd68463d7deff45aee436b742606/mupen64plus-rsp-hle/projects/unix/Makefile#L170
https://github.com/loganmc10/m64p/blob/4b2b64b72285dd68463d7deff45aee436b742606/mupen64plus-input-raphnetraw/projects/unix/Makefile#L124

[joeldenning]

Not sure I understand your latest comment, @Jj0YzL5nvJ, but the makefiles you linked to all work for me on OSX. Yes, m64p is downstream, but my understanding is that the makefiles are unaltered. Do those makefiles not work for you on osx?

[SpiceyWolf]

Not sure I understand your latest comment, @Jj0YzL5nvJ, but the makefiles you linked to all work for me on OSX. Yes, m64p is downstream, but my understanding is that the makefiles are unaltered. Do those makefiles not work for you on osx?

On catalina i am unable to build all of the makefiles without some alterations... It requires an export CXXFLAGS='-stdlib=libc++' to build core and rice, and on rsp cxd4 needs the strip command removed, and mk2 i just cloned my boost include folder into source folder

[joeldenning]

Sounds like you've made good progress then on building it on osx. Seems like the next logical step would be to incorporate some of those changes into the makefiles.

[Jj0YzL5nvJ]

Exactly, any change in "upstream" indirectly benefits "downstream". I'm summons you with hopes of goodwill as this concerns macOS users, although the problem does not appear to affect m64p to any great extent, it does not imply that the problem does not exist for other potential macOS users.
As you will see, this user wants to fix the problem but does not even understand why it does not require Qt, he only knows empirically that he does not need it.
We can let him break the brick wall alone or help him, that's all.

[SpiceyWolf]

Lol im still tryna get the binaries produced to actually run still... Havent had success with that just yet, but i come from linux and have a good idea how to troubleshoot... Ive submitted a pull request from mupen core for the working build as i stated above, willing to do for the rest if you guys want them (after I know the produced binaries WORK with the change... Building definitely does not seem to == working)

[Jj0YzL5nvJ]

P.S: I'm not macOS user, I'm Linux user and I can help to script things for Windows and Linux. But macOS is out of my league.

[SpiceyWolf]

Oof, core seems to die as soon as it invokes anything related to sdl

[SpiceyWolf]

o.o how did we go about changing the directory the dependencies are expected in? all of myne target the system files (think that may be part of why it wont work)

[Jj0YzL5nvJ]

O_o! Are you sure you are using brew?

o.o how did we go about changing the directory the dependencies are expected in?

https://github.com/mupen64plus/mupen64plus-video-glide64mk2/blob/aecf15ec2044c593b0505bd052270bd662902e08/projects/unix/Makefile#L192-L196
LDFLAGS += -L/your/custom/libs
CFLAGS += -I /your/custom/c_includes
CXXFLAGS += -I /your/custom/c++_includes

[SpiceyWolf]

Yes xD brew was the first thing installed on the machine

[SpiceyWolf]

Im attempting a hacky implementation of putting gcc on the mac in hopes to have this stuff compile without the quirks of the c++

[Jj0YzL5nvJ]

How ironic, I prefer to compile with Clang in Linux.

Some quirks are fixed by compiling with OPTFLAGS=-O2 instead of -O3.
Some others avoiding use dynarecs. #572, #738, #787

[SpiceyWolf]

I have been using the dynarec stuff just fine personally... And being on linux ive had 0 trouble building all the makefiles with gcc -> Just a simple make command in each repo and snag the lib and it runs without any problems. iirc I was able to build on arch and ubuntu without manually installing any deps, then just needed to install the official mupen package for the distro to resolve any runtime problems and it just worked (aka it pulled deps I didnt have that I somehow built without)

As a side note, the reason I'm even messing with mupen is I've been modding it and using with a C# frontend to make online multiplayer mods for games :D

I participated in an older group to make them using a nodejs binding (I had 0 help in creating that, the devs of the node-gyp stuff were even baffled how to resolve any wrapper troubles I encountered) and decided to split off and recreate it all in a better lang lol

This time around Im looking to get that mac support -> And if im lucky mobiles support too >: P

[Jj0YzL5nvJ]

That explains things... you lack practice. Messing with tools is an excellent exercise.

[SpiceyWolf]

Ive had this mac for maybe a week... The first time ive ever had a mac to play with outside of using them in kindergarten >.>

[bsmiles32]

You may also take a look at one of my old attempt at moving the build system to meson:
#488
It's not rebased against latest master, but may be an option to consider if you want to compile to other platform.

[richard42]

I just tried building on my macbook pro running macos 10.14 and was able to get it to build pretty easily. I pushed a few changes for a few small problems, but I didn't have any issue with OGLFT.cpp. I had to install mac ports and install packages for "pkgconfig" and "nasm", but that was it. I ran it with rice video and played space invaders and the graphics and sound and keyboard control worked fine. The osx_build_bundle script worked also, after I gave it the path to the libmupen64plus.dylib file which it had already moved into the bundle. You can download from here and test:
www.fascinationsoftware.com/media/mupen64plus-bundle-osx-20210210.zip

[retropieuser]

Hiya @richard42 I get a permissions error when attempting to access your zip file there from your website.
Out of curiosity, do you have your build instructions you undertook please

[richard42]

Yeah I have probably deleted that file since uploading it there in 2021. I didn't write down any build instructions for the mac - it should build just like in Linux. Use the helper scripts to clone the Git repositories for all of the modules and build everything with the makefiles.

[richard42]

Closing this issue because the latest source seems to build fine under MacOS 12.