MacOS X
MacOS X
Is there a guide to build pcem for macos x?
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: MacOS X
It's largely the same as for Linux. You need to install sdl2, wxmac and openal-soft through brew (https://brew.sh/), then run ./configure and make.
Re: MacOS X
I hope that someone will post a build guide for MacOS. I did manage to install brew, but I got lost from there on.
Re: MacOS X
I keep getting this error when trying to build for osx.
I am using high sierra 10.13.4.
In file included from cdrom-ioctl-osx.c:8:
In file included from /System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:42:
In file included from /usr/include/mach/mach_types.h:92:
/usr/include/mach/task_inspect.h:45:11: error: expected ';' at end of
declaration list
uint64_t cycles;
^
./ibm.h:181:25: note: expanded from macro 'cycles'
#define cycles cpu_state._cycles
^
I am using high sierra 10.13.4.
In file included from cdrom-ioctl-osx.c:8:
In file included from /System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:42:
In file included from /usr/include/mach/mach_types.h:92:
/usr/include/mach/task_inspect.h:45:11: error: expected ';' at end of
declaration list
uint64_t cycles;
^
./ibm.h:181:25: note: expanded from macro 'cycles'
#define cycles cpu_state._cycles
^
Re: MacOS X
huh... That looks like a conflict with a define used in ibm.h file. In other words, the define in ibm.h would need to have a different name.
Re: MacOS X
So I tried to compile PCem on macOS 10.12. It seems to compile successfully, but I noticed that 4 warnings were generated in fdi2raw.c, followed by another 2 warnings in pc.c, then this:
make[1]: .././install-sh: Permission denied
make[1]: *** [dosbox/.dirstamp] Error 1
make: *** [all-recursive] Error 1
Log supplied
make[1]: .././install-sh: Permission denied
make[1]: *** [dosbox/.dirstamp] Error 1
make: *** [all-recursive] Error 1
Log supplied
Re: MacOS X
I had to chmod a+x install-sh but then I got my error above.
Re: MacOS X
I got it to compile by commenting out /* uint64_t cycles; */ in the task_inspect.h. There is no networking so maybe I missed something else?
Re: MacOS X
I don't think the cdrom emulation under osx works good. When I insert a cd drive it crashes out. I will attach a log and my config.
Edit: It seems like it only craps out when I have a cd mounted at boot. I will let you know If I find anything else out.
Edit: It seems like it only craps out when I have a cd mounted at boot. I will let you know If I find anything else out.
Re: MacOS X
Do NOT modify system headers!!!! That is only going to cause you troubles.
As i said, the file that needs to be modified is ibm.h and replace the usage of the word "cycles" in there by something else (except, obviously, in cpu_state._cycles )
Also, even though the scripts (like install.sh) should work by default, it is recommended that you regenerate them with:
autoreconf -i
and then run ./configure and make
It usually isn't needed to call "make install" (pcem can be run from the source directory), but if you do so, you need to have admin privileges.
In order to enable networking, you need to explicitly say it so to ./configure, as in:
./configure --enable-networking --enable-release-build
As i said, the file that needs to be modified is ibm.h and replace the usage of the word "cycles" in there by something else (except, obviously, in cpu_state._cycles )
Also, even though the scripts (like install.sh) should work by default, it is recommended that you regenerate them with:
autoreconf -i
and then run ./configure and make
It usually isn't needed to call "make install" (pcem can be run from the source directory), but if you do so, you need to have admin privileges.
In order to enable networking, you need to explicitly say it so to ./configure, as in:
./configure --enable-networking --enable-release-build
Re: MacOS X
I was able to get it to compile on my Mac running OS X 10.11.6 but when I run pcem I get:
No ROMS present
Pcem did not create the ~/.pcem folder so I manually created it and copied my roms folder into that but I still get the error saying no roms are present. If I do "ls -a ~/" it shows .pcem as being there. Am I missing something?
No ROMS present
Pcem did not create the ~/.pcem folder so I manually created it and copied my roms folder into that but I still get the error saying no roms are present. If I do "ls -a ~/" it shows .pcem as being there. Am I missing something?
Re: MacOS X
@JosepMa I renamed the cycles in ibm.h to cycles1 and I still get the error
/usr/include/mach/task_inspect.h:45:11: error: expected ';' at end of declaration list
uint64_t cycles;
^
./ibm.h:181:25: note: expanded from macro 'cycles'
#define cycles cpu_state._cycles1
^
I have attached task_inspect.h maybe there is something wrong with it?
/usr/include/mach/task_inspect.h:45:11: error: expected ';' at end of declaration list
uint64_t cycles;
^
./ibm.h:181:25: note: expanded from macro 'cycles'
#define cycles cpu_state._cycles1
^
I have attached task_inspect.h maybe there is something wrong with it?
- Attachments
-
- task_inspect.h
- (1.96 KiB) Downloaded 436 times
Re: MacOS X
@jznomoney:
You did the opposite of what I told you to do:
You had this:
#define cycles cpu_state._cycles;
And I told you to do this:
#define cycles_ibm cpu_sate._cycles;
The problem is that you can't really do that without breaking the compilation, so you might have to do another workaround:
The contents of the cdrom-ioctl-osx.c starts like this:
@TonyM: Mmm.. looking a the file wx-sdl2.c it may be that under OSX, it applies the same than with Windows, which means that the roms have to be in the same folder than the built application. The ~/.pcem is definitely used under Linux.
You did the opposite of what I told you to do:
You had this:
#define cycles cpu_state._cycles;
And I told you to do this:
#define cycles_ibm cpu_sate._cycles;
The problem is that you can't really do that without breaking the compilation, so you might have to do another workaround:
The contents of the cdrom-ioctl-osx.c starts like this:
Add the #undef cycles line like this:#include <fcntl.h>
#include <sys/ioctl.h>
#include <stdlib.h>
#include "ibm.h"
#include "ide.h"
#include "cdrom-ioctl.h"
#include <util.h>
#include <IOKit/IOKitLib.h>
#include <IOKit/IOBSD.h>
#include <IOKit/storage/IOCDMedia.h>
#include <IOKit/storage/IOMedia.h>
#include <IOKit/storage/IOCDTypes.h>
#include <IOKit/storage/IOCDMediaBSDClient.h>
#include <IOKit/storage/IOMedia.h>
#include <errno.h>
static ATAPI ioctl_atapi;
#include <fcntl.h>
#include <sys/ioctl.h>
#include <stdlib.h>
#include "ibm.h"
#undef cycles
#include "ide.h"
#include "cdrom-ioctl.h"
#include <util.h>
#include <IOKit/IOKitLib.h>
#include <IOKit/IOBSD.h>
#include <IOKit/storage/IOCDMedia.h>
#include <IOKit/storage/IOMedia.h>
#include <IOKit/storage/IOCDTypes.h>
#include <IOKit/storage/IOCDMediaBSDClient.h>
#include <IOKit/storage/IOMedia.h>
#include <errno.h>
static ATAPI ioctl_atapi;
@TonyM: Mmm.. looking a the file wx-sdl2.c it may be that under OSX, it applies the same than with Windows, which means that the roms have to be in the same folder than the built application. The ~/.pcem is definitely used under Linux.
Re: MacOS X
The undef worked and pcem built fine. Unfortunately I can't use autireconf -i on mac because it messes up the configuration file and it can't locate sdl2.
when I run autoreconf -i I get this
Jamess-Mac:pcem jznomoney$ autoreconf -i
src/Makefile.am:18: warning: shell wx-config --rescomp: non-POSIX variable name
src/Makefile.am:18: (probably a GNU make extension)
src/Makefile.am:56: warning: subst -fpermissive,,$(shell wx-config --cxxflags: non-POSIX variable name
src/Makefile.am:56: (probably a GNU make extension)
src/Makefile.am:56: warning: shell sdl2-config --cflags: non-POSIX variable name
src/Makefile.am:56: (probably a GNU make extension)
src/Makefile.am:57: warning: shell wx-config --cxxflags: non-POSIX variable name
src/Makefile.am:57: (probably a GNU make extension)
src/Makefile.am:57: warning: shell sdl2-config --cflags: non-POSIX variable name
src/Makefile.am:57: (probably a GNU make extension)
/usr/local/Cellar/automake/1.16.1/share/automake-1.16/am/compile.am: warning: DEFAULT_INCLUDES was already defined in condition OS_WINDOWS, which is included in condition TRUE ...
src/Makefile.am:107: ... 'DEFAULT_INCLUDES' previously defined here
Then when I run ./configure
Jamess-Mac:pcem jznomoney$ ./configure --enable-networking --enable-release-build
checking build system type... x86_64-apple-darwin17.4.0
checking host system type... x86_64-apple-darwin17.4.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether to build for release... yes
checking whether to enable debugging... no
checking whether to enable networking... yes
checking whether to use ALSA for MIDI output... no
checking for cpu... x86_64
checking for off64_t... no
./configure: line 4318: syntax error near unexpected token `SDL,'
./configure: line 4318: ` PKG_CHECK_MODULES(SDL, sdl2 >= $min_sdl_version,'
I am going to attach the configure file
when I run autoreconf -i I get this
Jamess-Mac:pcem jznomoney$ autoreconf -i
src/Makefile.am:18: warning: shell wx-config --rescomp: non-POSIX variable name
src/Makefile.am:18: (probably a GNU make extension)
src/Makefile.am:56: warning: subst -fpermissive,,$(shell wx-config --cxxflags: non-POSIX variable name
src/Makefile.am:56: (probably a GNU make extension)
src/Makefile.am:56: warning: shell sdl2-config --cflags: non-POSIX variable name
src/Makefile.am:56: (probably a GNU make extension)
src/Makefile.am:57: warning: shell wx-config --cxxflags: non-POSIX variable name
src/Makefile.am:57: (probably a GNU make extension)
src/Makefile.am:57: warning: shell sdl2-config --cflags: non-POSIX variable name
src/Makefile.am:57: (probably a GNU make extension)
/usr/local/Cellar/automake/1.16.1/share/automake-1.16/am/compile.am: warning: DEFAULT_INCLUDES was already defined in condition OS_WINDOWS, which is included in condition TRUE ...
src/Makefile.am:107: ... 'DEFAULT_INCLUDES' previously defined here
Then when I run ./configure
Jamess-Mac:pcem jznomoney$ ./configure --enable-networking --enable-release-build
checking build system type... x86_64-apple-darwin17.4.0
checking host system type... x86_64-apple-darwin17.4.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether to build for release... yes
checking whether to enable debugging... no
checking whether to enable networking... yes
checking whether to use ALSA for MIDI output... no
checking for cpu... x86_64
checking for off64_t... no
./configure: line 4318: syntax error near unexpected token `SDL,'
./configure: line 4318: ` PKG_CHECK_MODULES(SDL, sdl2 >= $min_sdl_version,'
I am going to attach the configure file
- Attachments
-
- configure.txt
- (189.4 KiB) Downloaded 443 times
Re: MacOS X
also if I don't run autoreconf it builds fine as long as a chmod a+x install-sh.
Re: MacOS X
Ok. It seems that the wxwidgets part is not properly prepared for MacOS for autoreconf to work, so ok, keep the original copy of configure.
Re: MacOS X
I managed to build PCEM for MacOSX (running accros all sort of problem, as the uint_64 one), wxwidget installation & build, etc. After some hours, I got a build that I can launch, and even got some machine to work; before anything crash with a nasty error message about something wrong in the way thread are killed (will post the exact message). It seems that one thread are killed by another thread without doing some good things....
Keyboard emulation is totally messed up, no mouse emulation. I can't find a way to insert disk (no menu).
Keyboard emulation is totally messed up, no mouse emulation. I can't find a way to insert disk (no menu).
Re: MacOS X
Hello guys
I''m playing with PCem on a macOS for some time now, mostly with version v12 and the "old" wx-widgets fork but since it's now merged into the mainline I successfully managed to build and work with v14. Here are the details and instructions how to do it:
0. You must have Xcode Command Line tools installed (or Xcode itself), and some dependencies. Fortunately all of them are on Homebrew, easy to install:
1. Download the Linux version of the PCem, directly from Downloads section
3. Open Terminal and go to folder where you unpack the sources
2. Add executable flag for "install-sh" file:
3. Unfortunately with current version we need to change some lines in file "src/cdrom-ioctl-osx.c" - basically you need to move PCem header files under the system ones (IOKit) (the ones with "<>" brackets) and add "#undef CR0" before "#include ibm.h" - it's workaround but it works, probably should be fixed in a better way.
4.
5. (please note you can add "-j" flag with number of your threads to make build faster)
6. Now you should have "pcem" binary ready in the project folder. You can copy it to the target location, along with "roms", "screenshots", "configs" and "nvr" folders.
7. For some reason I didn't dig in, macOS version doesn't use home folder ".pcem" folder for looking for data, instead its starting from the directory its boot from. For me its fine, macOS version should put those files in proper "~/Library/Application Support" folder instead anyway.
BONUS about the menus: that was puzzling for me as well - apparently menu is available UNDER RIGHT CLICK on the emulated screen! BUT: if you have a touchpad, regular "ctrl-click" won't work You need either use regular mouse (better for emulation anyway) or double-tap gesture to make it work.
Hope it'll be helpful. It would also be nice to have official macOS port, not so big effort would need to be done: make it put into the application bundle like most Mac apps, use proper folder for data, add some icon and maybe put those menus to the top bar as they should.
Hope I helped
BR
Konrad
PS: v14 is better than v12 in my case in one major thing: looks like dynamic recompiler works in 64bit macOS build!
I''m playing with PCem on a macOS for some time now, mostly with version v12 and the "old" wx-widgets fork but since it's now merged into the mainline I successfully managed to build and work with v14. Here are the details and instructions how to do it:
0. You must have Xcode Command Line tools installed (or Xcode itself), and some dependencies. Fortunately all of them are on Homebrew, easy to install:
Code: Select all
$ brew install wxmac sdl2 openal-soft
3. Open Terminal and go to folder where you unpack the sources
2. Add executable flag for "install-sh" file:
Code: Select all
$ chmod +x install-sh
4.
Code: Select all
./configure
Code: Select all
make
6. Now you should have "pcem" binary ready in the project folder. You can copy it to the target location, along with "roms", "screenshots", "configs" and "nvr" folders.
7. For some reason I didn't dig in, macOS version doesn't use home folder ".pcem" folder for looking for data, instead its starting from the directory its boot from. For me its fine, macOS version should put those files in proper "~/Library/Application Support" folder instead anyway.
BONUS about the menus: that was puzzling for me as well - apparently menu is available UNDER RIGHT CLICK on the emulated screen! BUT: if you have a touchpad, regular "ctrl-click" won't work You need either use regular mouse (better for emulation anyway) or double-tap gesture to make it work.
Hope it'll be helpful. It would also be nice to have official macOS port, not so big effort would need to be done: make it put into the application bundle like most Mac apps, use proper folder for data, add some icon and maybe put those menus to the top bar as they should.
Hope I helped
BR
Konrad
PS: v14 is better than v12 in my case in one major thing: looks like dynamic recompiler works in 64bit macOS build!
-
- Posts: 2
- Joined: Wed 23 Jan, 2019 3:30 pm
- Contact:
Re: MacOS X
I'm using Mojave (10.14.2) and I was able to compile PCem successfully, and even launch the configuration selection screen, but when it actually tries to start a VM, the window flashes briefly then crashes with the following error:
It appears that Mojave is placing more explicit restrictions on updating windows from non-main threads.
Based on the above stack trace, I went into the code and commented out the set_window_title() call in the runpc() function (pc.c:592), and it actually worked without any further problems!
So it's something to do with updating the window title (?) from a non-main thread, but I'm guessing Mojave might have other issues with other window-related functions from non-main threads, so perhaps the management of the window position/dimensions/title might need to be updated. I have no experience with WX and/or SDL development, so I can't diagnose further, but I thought I'd share this observation and a possible solution.
Code: Select all
2019-01-22 22:05:55.711 pcem[13904:39449] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff4813fecd __exceptionPreprocess + 256
1 libobjc.A.dylib 0x00007fff741fb720 objc_exception_throw + 48
2 CoreFoundation 0x00007fff4815995d -[NSException raise] + 9
3 AppKit 0x00007fff4565ac8e -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
4 AppKit 0x00007fff4567ce2a -[NSThemeFrame _tileTitlebarAndRedisplay:] + 98
5 AppKit 0x00007fff456a7eed -[NSTitledFrame _titleDidChange] + 217
6 AppKit 0x00007fff456a7995 -[NSTitledFrame setTitle:] + 730
7 AppKit 0x00007fff456a760c -[NSThemeFrame setTitle:] + 50
8 AppKit 0x00007fff4566aa72 -[NSWindow _dosetTitle:andDefeatWrap:] + 211
9 libSDL2-2.0.0.dylib 0x000000010e320cea Cocoa_SetWindowTitle + 110
10 pcem 0x000000010ac6f09e runpc + 1054
11 pcem 0x000000010ad5d1c1 mainthread + 145
12 libSDL2-2.0.0.dylib 0x000000010e2c59b5 SDL_RunThread + 60
13 libSDL2-2.0.0.dylib 0x000000010e325aa7 RunThread + 9
14 libsystem_pthread.dylib 0x00007fff754bd305 _pthread_body + 126
15 libsystem_pthread.dylib 0x00007fff754c026f _pthread_start + 70
16 libsystem_pthread.dylib 0x00007fff754bc415 thread_start + 13
)
Based on the above stack trace, I went into the code and commented out the set_window_title() call in the runpc() function (pc.c:592), and it actually worked without any further problems!
So it's something to do with updating the window title (?) from a non-main thread, but I'm guessing Mojave might have other issues with other window-related functions from non-main threads, so perhaps the management of the window position/dimensions/title might need to be updated. I have no experience with WX and/or SDL development, so I can't diagnose further, but I thought I'd share this observation and a possible solution.