Question: How to build on MacOS with SDL2

[sairoutine]

Hi! I'm trying to execute following command to build with SDL2 on MacOS.

./configure --enable-core-inline --enable-debug=heavy --prefix=/usr --enable-sdl2
make -j3

But following url's error has occured. https://gist.github.com/sairoutine/17027d400ec665e1a094a4d21448498f

Any ideas to succeed to build?

Environment Mac X EI Capitan 10.11.6 dosbox-x 0.82.8

[joncampbell123]

Use ./build-debug-sdl2

[sairoutine]

Thank you. But if I try to build by ./build-debug-sdl2, An error similar to issue https://github.com/joncampbell123/dosbox-x/issues/840 occurred.

my ffmpeg version is 4.0.2.

[sairoutine]

I looked at issue https://github.com/joncampbell123/dosbox-x/issues/719 and understood that ffmpeg ver 4 is the problem. So I tried to build with ffmpeg 2.8, the error similar to issue top occurred.

g++  -g -O2 -std=gnu++0x -msse  -Wall   -Wextra   -pedantic   -Wconversion-null   -Wno-implicit-fallthrough   -Wno-strict-aliasing   -Wno-missing-field-initializers   -Wno-format-zero-length   -Wno-address-of-packed-member   -Wno-int-to-void-pointer-cast   -Wno-extended-offsetof   -mmmx -msse -msse2  -L/usr/local/opt/ffmpeg@2.8/lib  -o dosbox-x dosbox.o  debug/libdebug.a dos/libdos.a shell/libshell.a builtin/libbuiltin.a ints/libints.a misc/libmisc.a hardware/serialport/libserial.a hardware/parport/libparallel.a libs/porttalk/libporttalk.a gui/libgui.a libs/gui_tk/libgui_tk.a hardware/libhardware.a cpu/libcpu.a hardware/reSID/libresid.a fpu/libfpu.a gui/libgui.a aviwriter/libaviwriter.a output/liboutput.a xBRZ/libxbrz.a mt32/libmt32.a -framework CoreMIDI -framework AudioUnit -framework AudioToolbox -L/usr/local/lib -lSDL2 -lcurses -lz -lpng -lz -lpcap -lavcodec -lavformat -lavutil -lswscale
Undefined symbols for architecture x86_64:
  "_FSPathMakeRef", referenced from:
      MidiHandler_coreaudio::Open(char const*) in libgui.a(midi.o)
  "___CFConstantStringClassReference", referenced from:
      CFString in libgui.a(midi.o)
      CFString in libgui.a(midi.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [dosbox-x] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

[joncampbell123]

@sairoutine Try FFMPEG 3.0.11 or FFMPEG 3.2. You may also try editing build-debug-sdl2 and removing --enable-avcodec if you do not need the ability to capture gameplay to an MTS file.

[sairoutine]

Thank you for your advice. I tried FFMPEG 3.2, and also built with removing --enable-avcodec, but similar error ld: symbol(s) not found for architecture x86_64 occured.

[sairoutine]

I've solved. With adding Carbon and CoreFoundation framework to ld options, I succeeded to build and execute dosbox-x.

diff --git a/build-debug-sdl2 b/build-debug-sdl2
index bd2f99f..0d54e4f 100755
--- a/build-debug-sdl2
+++ b/build-debug-sdl2
@@ -14,8 +14,11 @@ if test -z "$x" ; then
     echo Compiling our internal SDL 2.x
     (cd vs2015/sdl2 && ./build-dosbox.sh) || exit 1
 fi
+new="-framework CoreFoundation -framework Carbon "
+export LDFLAGS="$new$LDFLAGS"

Thank you for your advice!

[joncampbell123]

I'll pull out my Mac Mini and see if adding the LDFLAGS causes any issues. It sounds like direct references to the Carbon and CoreFoundation libraries may be required on some Mac OS X systems where the configure script fails to detect them.

[brunocastello]

There is an issue with macOS SDL2 version - when the mouse is over the DOSBox, the main menu keeps persistently open and the user cannot close it. SDL1 without the menu works fine.

[joncampbell123]

You're using a macbook with a trackpad, correct?

That is a known issue that SDL2 reports trackpad input as both mouse and touch input at the same time, which confuses my menu code.

I don't know yet how to resolve the issue.

[brunocastello]

@joncampbell123 yeah, that's correct, a macbook with trackpad. Thanks for explaining this to me. Anyway, this is the reason I am testing with the SDL1 version.

[joncampbell123]

Thought so.

I do my Mac OS X testing on a Mac Mini, which has only a USB mouse to test with. I do not have a macbook to test against, so I do not have hardware I can use to resolve the issue.

[barbeque]

@joncampbell123 It might be off-topic for this specific issue, but it looks like there are special 'finger' SDL events (SDL_FINGERDOWN) that are being captured and forwarded to mouse clicks in src/gui/sdlmain.cpp

I don't know if getting rid of touch gestures altogether is something you want to entertain (phones?) but they could also just be put behind a #define gate.

Probably better to have this in its own issue if you want to pursue it further.

[joncampbell123]

I would ignore SDL_FINGER events except that it makes it impossible to use the menus with the touchscreen on my laptop.

SDL 2.x does not provide mouse input from touchscreen events AT ALL, unlike SDL 1.x which will forward the OS's emulation of mouse events from touchscreen.

[joncampbell123]

What complicates things is that SDL_FINGER events are supposed to represent coordinates in the scale 0.0 to 1.0, but some OS and SDL 2 combinations (including Linux/X11) report touchscreen position in pixels.

[barbeque]

Wow, fast response! Would it be best for now to just add a platform gate and ignore them on macOS then? That would help with some of the twitchiness that you get on a MacBook's touchpad.

[joncampbell123]

Sure. You won't be able to bring them up with the touchscreen, but if that makes it more usable, I'm all for it.

I can make the modification, however the only Mac OS system I have to test is a Mac mini, so I will need feedback from anyone here with a Macbook whether it helps.

[barbeque]

I'd be happy to test for you. I think the video scaling factor is also a little off on my mid-2012 Retina MBP, but that might have been how I built it (piecing things together from this very thread).

[joncampbell123]

@barbeque If you can, compile Mac OS X from source the latest commit. HighDPI support and a SDL2 update might resolve the issue.

[barbeque]

Same problem - graphics are at least 2X scaled. I am using the homebrew version of SDL2, it seems (-lSDL2) but I don't think that has anything to do with it.

I used the ./build-macosx-sdl2 script (nice!) I had to modify configure.ac:371 to add -framework Cocoa to the LIBS var, otherwise it wouldn't link.

I copied the log output from -debug -early-debug (the console complains of a missing logfile but --help doesn't seem to document an option for it)

Here is the log: early-log.txt

[joncampbell123]

The latest commits replaced the SDL2 library. SDL2 v2.0.5 was replaced with SDL2 v2.0.9 which fixes that issue on my end. Run ./build-debug-sdl2 again to recompile from scratch.

[barbeque]

With the ./build-debug-sdl2 script, I get a more usable but still pixel-doubled screen. It says in the console it built against SDL 2.0.8:

LOG:          0 DEBUG GUI:This version compiled against SDL 2.x
LOG:          0 DEBUG GUI:SDL2 version 2.0.8

The bundled SDL2 is indeed 2.0.9 so I'm thinking it might still be trying to link against the homebrew SDL2 (perhaps the config script is using sdl2-config and needs to force LD_LIBRARY_PATH or something similar instead?)

I am updating my homebrew SDL2 to 2.0.9 from 2.0.8 & will try to build again.

[barbeque]

Yep - against 2.0.9 this is way better - the splash screen appears, the window resizes itself properly, and everything is in the right scale.

So indeed, 2.0.9 fixes it, I just need to figure out why the included SDL2 isn't getting linked against.

As an aside: I am still getting what appear to be touch events from the trackpad, it makes it hard to use the menus. I assume this hasn't been touched yet, I might have some time over the holiday break to look at it again and contribute a PR to platform-gate this feature like we discussed further upthread.

[joncampbell123]

@brunocastello I just purchased a Macbook Pro to continue developing DOSBox-X support and... yes, the menus act as if reacting to both the mouse cursor and "touch input". Apparently SDL2 registers touch events from the touchpad. SDL2 sees the touchpad as a hand-sized touchscreen apparently!

Since Apple has apparently taken the attitude of not putting touchscreens on their Macbooks, I'm going to go ahead and filter out touchscreen handling entirely for OS X builds.

[joncampbell123]

Pull the latest commit and compile on OS X, touch events in SDL2 builds are ignored now, which makes DOSBox-X usable.

[joncampbell123]

Aarrrgh, I see that on this Macbook pro, scaling by the backbuffer scale works except Mojave for some reason is also applying some other sort of scaling to the screen. Bleh.

[brunocastello]

@joncampbell123 nice! I will test when I have a chance. Though I don’t know how to compile. I am right now doing a Hackintosh in a Dell G7 7588 - since I don’t have the re$ource$ for a new macbook pro (here in Brazil they are the price of a car!! shock). Once I get everything up and running (I am very close to it) I cannot wait to try your new version. Thanks! :)

PS: I still have the mbAir, just don’t want to use it too much, as I want to sell it later when I finish my hackintosh.

[joncampbell123]

Oh I see.....

Apparently the screen is small enough that Mac OS X is rendering the screen at some high resolution, then scaling it down for the laptop display.

So when DOSBox-X compensates for HighDPI, it still looks scaled on the screen, but if I connect to it over VNC, I see that the pixel perfect matching is still working.

EDIT: You can go into Display settings and manually set the scaling to 1:1, but the default is to scale down slightly.

[joncampbell123]

I do know from experience that most GPUs (Intel included) have support for setting the framebuffer to a resolution higher than supported by the LCD display, which the GPU can scale down to the LCD display.

[joncampbell123]

Just for the hell of it I got a model with the "touch bar" because, well, it might be something fun to experiment with, and perhaps DOSBox-X can support it for shortcuts.

[brunocastello]

Yeah, they do. Some hackintoshes with intel GPU do have some framebuffer patches. I wouldn’t recommend trying it in a real mac.

But I think I know what’s going on - you have a Retina mbpro, right? I use one at work (2015 model) and when I go to display settings and you have five options for hdpi to choose, I prefer the middle one - I work with an external monitor too, to extend it.

But the hdpi resolution may vary depending of your dosbox-x users - some might prefer more, some less. I think it might be difficult to scale correctly, no?

[joncampbell123]

I can go into Display settings and manually set a scale that lets 1:1 matching work, yes. The default seems to be somewhat scaling down. It's fine, it's just something to consider if you enable HighDPI mode and then the DOS window still looks scaled.

EDIT: Of course I got one with a retina display. It helps me test HighDPI support.

[brunocastello]

The touchbar is cool, but after having tried it on my dad’s macbook, I wasn’t so impressed. It might be useful for designers maybe (Photoshop/Illustrator/XD artists) like me, who rely a lot on shortcuts. You could have saved some $$ buying one without the touchbar - xcode does have touchbar emulation, which works well.

[joncampbell123]

Unfortunately I install XCode only to get the command line GCC and linker tools, I don't use the GUI part. I compile and develop from the Terminal, either locally or from my Linux box over SSH.

[joncampbell123]

I'd rather use the existing shell scripting autoconf stuff than try to stuff it into an XCode project. Maintaining VS2017 project files alongside the Linux makefiles is enough.

[brunocastello]

I can understand it. Every developer has his own unique workflow. What works and is faster, we get used to it and it’s difficult to change later :P

[joncampbell123]

Certainly! XCode provides "gcc" and "ld", and then I can use "Homebrew" to install the GNU autotools and other libraries I'm used to having on Linux. It's fine.

[joncampbell123]

It means I can use the same configure.ac and shell scripts on Linux and Mac OS X and it works. MinGW makes it possible to also use the same configure.ac on Windows too (within the MinGW shell).

[emendelson]

For those of us who want to avoid Homebrew and Port, because they sometimes produce strange results in software that we distribute to other machines, it's easy to install the autotools using this script:

http://munchpress.com/installing-autoconf-automake-libtool-on-mac-osx-mountain-lion/

Some of the tools have been updated, but the versions obtained with that script still seem to work.

P.S. Xcode includes libtool, but I'm not sure whether the downloaded autoconf and automake will work with the libtool in Xcode; at least I've never tried it.

[brunocastello]

@joncampbell123 I've finally finished setting up my hackintosh with Mojave (though just missing a few fixes for hibernation and color banding on screen), and I'll later download and test your latest release this weekend. If it does include ne2000 emulation, I believe I will have some trouble in getting it to work. Last time I tried (5 months ago) I was on my macbook air, with High Sierra installed, and it was unable to find any network interface.

[brunocastello]

@joncampbell123 tried your latest release, works fine now. Nice!

Like I said before, I have no clue on why I can’t find a network interface, when I am emulating Win 3.11. I must be missing something in any macOS setting. Can’t be pcap, macOS comes with it.

[joncampbell123]

I just ran NE2000 emulation on OS X.

The error message in the log (with --debug) says that the NE2000 emulation failed to load because Mac OS X says that DOSBox-X does not have permission to capture network traffic.

If NE2000 emulation isn't working on Mac OS X, try running DOSBox-X with the "sudo" command.

[brunocastello]

I tried running as sudo before because I saw on Vogons forums that someone tried to run a patched dosbox svn with NE2000 on macOS, and it didn’t work either. I set the realnic to “list”, and when I see the debug, it lists a few interfaces with no description of them; meaning it didn’t work (even if I select one, it still does not work.)

I think that libpcap on macOS need some kind of modification to work. Here what’s I was told to do when I tried the app last year: https://www.vogons.org/viewtopic.php?f=33&t=55840#p611291

But I couldn’t figure out what exactly I had to do.

[brunocastello]

Actually someone posted about how to fix it for dosbox-x ne2000 to work on macOS. The author doesn't know why it works. I haven't tried because I cannot for the life of me compile dosbox-x on macOS Mojave. First I try the build-macosx, then it complains about some unsafe dir for libpng. And I tried to run the configure script, which then complained about SDL > 1.2.0 not present (even though I had done a brew install sdl2 before).

No idea why I cannot compile. Anyway, the lines mentioned by someone about the ne2000 patch are here: https://www.vogons.org/viewtopic.php?p=734565#p734565

[joncampbell123]

DOSBox-X uses it's own internal SDL1 library that has been heavily modified from the original. It cannot use the stock SDL1 library. However by design it supports the stock SDL2 library (./build-macosx-sdl2)

What is the error message for the "unsafe libpng directory?".

Perhaps DOSBox-X needs to use it's own internal copy of libpng and zlib.

[brunocastello]

OK, so I did a git clone https://github.com/joncampbell123/dosbox-x dosbox-x, repo cloned OK.

When I try ./build-macosx: configure: error: cannot find install-sh or install.sh in /Volumes/MacBruno HD/Users/Bruninho/Downloads/dosbox-x/vs2015/sdl/build-scripts

When I try ./build-macosx-sdl2: checking whether build environment is sane... configure: error: unsafe srcdir value: '/Volumes/MacBruno HD/Users/Bruninho/Downloads/dosbox-x/vs2015/libpng'

Both fails, I don't even try to run ./configure because I know it will complain about sdl being absent.

Tried it on macOS 10.14.3 (Mojave).

[brunocastello]

OK, I figured out what went wrong. The compiler probably didn't like the space in my drive name (MacBruno HD) so I moved the files to another volume with no spaces and ran the build-debug-sdl2, but before I applied two modifications to ne2000.cpp I saw from a forum post on Vogons (https://www.vogons.org/viewtopic.php?f=33&t=55840&p=735370#p735370) and got the app compiled. Then I ran it as root with a disk image of Win95 from terminal. While watching the debug, the system booted successfully, but the console reported that no network interfaces were found (there was a list of network interfaces, but they do not have descriptions, so no go.

[brunocastello]

The output:

Network Interface List

LOG: 1. en0 (no description) LOG: 2. p2p0 (no description) LOG: 3. awdl0 (no description) LOG: 4. utun0 (no description) LOG: 5. en1 (no description) LOG: 6. lo0 (no description) LOG: 7. gif0 (no description) LOG: 8. stf0 (no description) LOG: 9. XHC0 (no description) LOG: 10. XHC20 (no description)

[joncampbell123]

I should check the makefiles and scripts then for possible issues with paths that have spaces.

When compiling for Mac OS X please use ./build-macosx or ./build-macosx-sdl2

[brunocastello]

@joncampbell123 : did you get a way to set up HighDPI on Dosbox-X configuration files?

I managed to get mine to connect to the internet, finally. When I boot I have to set up manually: HighDPI enable, Force scaler, Normal2x, Output OpenGL (I'm using the SDL1.x version) This way I get a very good resolution to play with my screen.

[brunocastello]

Just forgot to mention... for NE2000, you have to change a line to make it work with macOS (Mojave only? IDK): https://www.vogons.org/viewtopic.php?p=734565#p734565

I did it before I compile dosbox-x and it works now. I now want to find a way to keep my own dosbox.conf and disk image (to boot MSDOS 6.22 and WFWG3.11) in a folder to sync with OneDrive, so I could play it in any of my computers. I also need to find a one-click solution to launch it.