robertmo wrote on 2020-08-30, 03:57:

i guess it won't hurt if you meanwhile try this
https://discussions.apple.com/thread/8336714

Thank you, I'll read it and see if I can give it a try.

Edit: Still out of luck. Same errors. =(

in the configure log you should have marked if it is still using clang or not

robertmo wrote on 2020-08-30, 05:10:

in the configure log you should have marked if it is still using clang or not

This is what I used:

1MacBruno-Pro:~ Bruninho$ ../qemu-4.1.1/configure --cc=gcc-10 --cxx=g++-10 --host-cc=gcc-10 --target-list=i386-softmmu,x86_64-softmmu && make

Then it gave me the same errors as before regarding OpenGL, so I changed it to use -framework OpenGL instead of -lGLX, and tried again... this time, while it were really building with gcc-10, at the end it gave me a different error, about coreaudio.o this time.

Anyway, as stated by @kjliew, Grand Prix 4 will not have on QEMU the same performance or get any close to the performance I have on VMware Fusion, so It's a waste of time from my part to try it.

I'll just limit the old games to DOSBox-X on my Mac, and do the same on my iPad Pro with UTM. As for Grand Prix 4, I'm afraid I'll have to take the dust out of my old i7 hackintosh mini, rebuild it to an even more smaller pc case, and install only Windows XP just for that game in particular. It would need my logitech G27 steering wheel/pedals to play anyway, so no point in using my macbook for that game in particular. It's not like if it was a game to play on the go when I'm not at home.

I couldn't care less about the garbage that is Windows 10. I guess that the standard QEMU will suffice for any linux distro as guest. That way I can give the middle finger to VMware/Parallels expensive solutions.

i guess it should look this way in the configure log
C compiler cc
Host C compiler cc
C++ compiler c++
Objective-C compiler cc

Can you provide more details steps of how you compiled QEMU 4.11 with clang on macOS without the patch?

If you applied the patch and compiled with clang on macOS with errors, then you should redirect stdout to capture the build log.
From the last step:

1$ ../qemu-4.1.1/configure
2$ make 2>&1 | tee build.log

Attach the build.log and I will take a look.

Sure. I can try again tomorrow after the Belgian F1 GP.

kjliew wrote on 2020-08-30, 07:15:

Can you provide more details steps of how you compiled QEMU 4.11 with clang on macOS without the patch?

1$ wget https://download.qemu.org/qemu-4.1.1.tar.xz
2$ tar xf qemu-4.1.1.tar.xz
3$ cd qemu-4.1.1
4./configure && make -j3

OK, here's the reports. For the entire process, I am using Apple's clang.

This produced QEMU 4.1.1 binaries which I later tested with a pre-existing OS X Snow Leopard VM I had on UTM. So both 5.1.0 (from homebrew) and 4.1.1 (compiled now) qemu-system-ppc worked OK.

kjliew wrote on 2020-08-30, 07:15:

If you applied the patch and compiled with clang on macOS with errors, then you should redirect stdout to capture the build log. […]
Show full quote

If you applied the patch and compiled with clang on macOS with errors, then you should redirect stdout to capture the build log.
From the last step:

Copy code to clipboard

1$ ../qemu-4.1.1/configure
2$ make 2>&1 | tee build.log

Attach the build.log and I will take a look.

Here, I'm now following the instructions on the github page and using QEMU 4.1.1 to patch.

Without modifying the -lGLX to -framework OpenGL inside configure, it didn't even started so there was no build.log to show. The error was:

1ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
2       You probably need to set PKG_CONFIG_LIBDIR
3       to point to the right pkg-config files for your
4       build target

Setting PKG_CONFIG_LIBDIR did not solve it at all in previous posts, so I investigated and apparently I had to change -lGLX to -framework OpenGL.

Then I did the change and it started to build but later it failed on me. Attached is the build.log with the errors which failed:

Worth mentioning that a second attempt targeting only i386 and x86_64 still produces the same kind of error.

I think I found the issue. Just to be sure, can you please attach the the following files from macOS build?

1config-host.mak
2config-host.h

They are generated by QEMU from in the same folder that you run configure && make.
I think I missed out some of the platform stuffs handling for macOS.

kjliew wrote on 2020-08-30, 20:20:

I think I found the issue. Just to be sure, can you please attach the the following files from macOS build? […]
Show full quote

I think I found the issue. Just to be sure, can you please attach the the following files from macOS build?

Copy code to clipboard

1config-host.mak
2config-host.h

They are generated by QEMU from in the same folder that you run configure && make.
I think I missed out some of the platform stuffs handling for macOS.

You mean the ones from the QEMU 4.1.1 compiled with or without your patch?

EDIT: I've attached both. These are from the second attempt earlier - the ones for x86_64 and i386 targets only.

Thanks, one more file for SDL2 platform stuffs

1SDL2_config.h

kjliew wrote on 2020-08-30, 21:34:

Thanks, one more file for SDL2 platform stuffs […]
Show full quote

Thanks, one more file for SDL2 platform stuffs

Copy code to clipboard

1SDL2_config.h

That file does not exist in both patched and non-patched.

This file is not part of QEMU, it is part of your build environment libraries. For Linux, it is typically in /usr/include/SDL2 or /usr/local/include/SDL2. You have to figure it out on macOS for homebrew or MacPort.
And, you need to disable Apple COCOA and enable SDL2 for QEMU.

1--disable-cocoa --enable-sdl

Glide and MESA GL pass-through plumbing into QEMU UI handling only work for SDL/SDL2. Platform specific native display libraries (such as gtk, cocoa etc.) are not supported.
When QEMU configure script finished, it displayed a summary of configured features and libraries. Please attach that.

kjliew wrote on 2020-08-30, 21:53:

This file is not part of QEMU, it is part of your build environment libraries. For Linux, it is typically in /usr/include/SDL2 o […]
Show full quote

This file is not part of QEMU, it is part of your build environment libraries. For Linux, it is typically in /usr/include/SDL2 or /usr/local/include/SDL2. You have to figure it out on macOS for homebrew or MacPort.
And, you need to disable Apple COCOA and enable SDL2 for QEMU.

Copy code to clipboard

1--disable-cocoa --enable-sdl

Glide and MESA GL pass-through plumbing into QEMU UI handling only work for SDL/SDL2. Platform specific native display libraries (such as gtk, cocoa etc.) are not supported.

Okay, Give me some minutes to find it out

EDIT: Found it inside /usr/local/Cellar/sdl2/2.0.12_1/include/SDL2 for the homebrew version.

I also happen to have DOSBox-X, I've built both SDL1 and SDL2 versions yesterday, so for sure I have SDL2...

kjliew wrote on 2020-08-30, 21:53:

When QEMU configure script finished, it displayed a summary of configured features and libraries. Please attach that.

You mean this?

1MacBruno-Pro:build Bruninho$ ../qemu-4.1.1/configure --target-list=i386-softmmu,x86_64-softmmu && make -j3
2Install prefix    /usr/local
3BIOS directory    /usr/local/share/qemu
4firmware path     /usr/local/share/qemu-firmware
5binary directory  /usr/local/bin
6library directory /usr/local/lib
7module directory  /usr/local/lib/qemu
8libexec directory /usr/local/libexec
9include directory /usr/local/include
10config directory  /usr/local/etc
11local state directory   /usr/local/var
12Manual directory  /usr/local/share/man
13ELF interp prefix /usr/gnemul/qemu-%M
14Source path       /Users/Bruninho/myqemu/qemu-3dfx/qemu-4.1.1
15GIT binary        git
16GIT submodules
17C compiler        cc
18Host C compiler   cc
19C++ compiler      c++
20Objective-C compiler clang
21ARFLAGS           rv
22CFLAGS            -O2 -g
23QEMU_CFLAGS       -I/usr/local/Cellar/pixman/0.40.0/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt  -I/usr/local/Cellar/glib/2.64.5/include -I/usr/local/Cellar/glib/2.64.5/include/glib-2.0 -I/usr/local/Cellar/glib/2.64.5/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.44/include -m64 -mcx16 -DOS_OBJECT_USE_OBJC=0 -arch x86_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99  -Wno-string-plus-int -Wno-typedef-redefinition -Wno-initializer-overrides -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/local/Cellar/gnutls/3.6.14/include -I/usr/local/Cellar/nettle/3.6/include -I/usr/local/Cellar/libtasn1/4.16.0/include -I/usr/local/Cellar/libidn2/2.3.0/include -I/usr/local/Cellar/p11-kit/0.23.20_1/include/p11-kit-1 -I/usr/local/Cellar/nettle/3.6/include   -I/usr/local/Cellar/libpng/1.6.37/include/libpng16 -I$(SRC_PATH)/capstone/include
24LDFLAGS           -framework Hypervisor -m64 -framework CoreFoundation -framework IOKit -arch x86_64 -g
25QEMU_LDFLAGS      -L$(BUILD_DIR)/dtc/libfdt
26make              make
27install           install
28python            python3 -B (3.8.5)
29slirp support     internal
30smbd              /usr/sbin/smbd
31module support    no
32host CPU          x86_64
33host big endian   no
34target list       i386-softmmu x86_64-softmmu
35gprof enabled     no
36sparse enabled    no
37strip binaries    yes
38profiler          no
39static build      no
40Cocoa support     yes
41SDL support       no
42SDL image support no
43GTK support       no
44GTK GL support    no
45VTE support       no
46TLS priority      NORMAL
47GNUTLS support    yes
48libgcrypt         no
49nettle            yes (3.6)
50libtasn1          yes
51PAM               yes
52iconv support     yes
53curses support    no
54virgl support     no
55curl support      yes
56mingw32 support   no
57Audio drivers     coreaudio
58Block whitelist (rw)
59Block whitelist (ro)
60VirtFS support    no

61Multipath support no
62VNC support       yes
63VNC SASL support  yes
64VNC JPEG support  yes
65VNC PNG support   yes
66xen support       no
67brlapi support    no
68bluez  support    no
69Documentation     no
70PIE               no
71vde support       yes
72netmap support    no
73Linux AIO support no
74ATTR/XATTR support no
75Install blobs     yes
76KVM support       no
77HAX support       yes
78HVF support       yes
79WHPX support      no
80TCG support       yes
81TCG debug enabled no
82TCG interpreter   no
83malloc trim support no
84RDMA support      no
85PVRDMA support    no
86fdt support       git
87membarrier        no
88preadv support    no
89fdatasync         no
90madvise           yes
91posix_madvise     yes
92posix_memalign    yes
93libcap-ng support no
94vhost-net support yes
95vhost-crypto support yes
96vhost-scsi support no
97vhost-vsock support no
98vhost-user support yes
99Trace backends    log
100spice support     no
101rbd support       no
102xfsctl support    no
103smartcard support no
104libusb            yes
105usb net redir     no
106OpenGL support    no
107OpenGL dmabufs    no
108libiscsi support  no
109libnfs support    no
110build guest agent yes
111QGA VSS support   no
112QGA w32 disk info no
113QGA MSI support   no
114seccomp support   no
115coroutine backend sigaltstack
116coroutine pool    yes
117debug stack usage no
118mutex debugging   no
119crypto afalg      no
120GlusterFS support no
121gcov              gcov
122gcov enabled      no
123TPM support       yes
124libssh support    yes
125QOM debugging     yes
126Live block migration yes
127lzo support       yes
128snappy support    yes
129bzip2 support     yes
130lzfse support     no
131NUMA host support no
132libxml2           yes
133tcmalloc support  no
134jemalloc support  no
135avx2 optimization no
136replication support yes
137VxHS block device no
138bochs support     yes
139cloop support     yes
140dmg support       yes
141qcow v1 support   yes
142vdi support       yes
143vvfat support     yes
144qed support       yes
145parallels support yes
146sheepdog support  yes
147capstone          internal
148docker            no
149libpmem support   no
150libudev           no
151default devices   yes

Alright, this is going to be complicated, unfortunately. I was looking for an easier path to use GLX/X11 on macOS, but this was not as simple as I thought. This was a deprecated, unfavoured approach and Apple had since freezed the time for anyone trying to do that, by capping the OpenGL at 2.1. To do this anyway, AFAIK you will need XQuartz (X.Org server) and SDL2 with X11 support by recompiling it with "--with-x=yes", in addition to Apple/Cocoa native UI library. When I inspected the SDL_config.h, it only supports Cocoa and no X11. Not surprising for something that was part of planned obsolesce. And I presume the performance will not be as good as what being supported on Windows and Linux.

So the correct way to support macOS is to add OpenGL context creation through Cocoa/NSOpenGL. Since I am not an Apple developer, this will be quite challenging to pull this out without accessing to systems with macOS. So I think I will just drop macOS support . Hopefully, someone more adept at macOS software development will be able to contribute the codes in future.

So, thats bad news for me then...

I’m guessing that I will have to move forward with plan B... leave more modern games like GP4 to a small pc box with XP and move the older ones to DosBox-X or PCem on my mac for gaming on the go. Hopefully I can get FIFA 98 with proper 3dfx in one of these emulation options.

I was betting on QEMU as an all in one solution for both future arm macs and my iPad Pro (with UTM). Doesn’t look like DosBox-X and DosPad devs will work together to bring the dosbox-x features to on iOS, despite the fact that I have talked to both and both seemed to be receptive to the idea. Dospad hasn’t been updated in years and is way behind latest dosbox svn version.

I can play Fifa98 on UTM with win98se vm, but its software rendered instead of 3dfx, so graphics are a bit worse and playable & not so slow as I expected it to be. Let’s see what I can do now...

Updating...

I spent a couple of hours setting up a win98se machine on dosbox-x. While it was working well and had 3dfx/voodoo, the machine performance was worse than its QEMU counterpart. I haven’t tested any game but the overall feel was that it was a bit slower. Much slower.

I have a feeling that PCem will not be any better.

Meanwhile, I copied the win98se machine I had on my iPad Pro running in UTM to my mac and put it to test with QEMU 5.1.0 (latest UTM uses 4.2.0). I had the impression that on my mac the speed was practically the same. That is, a 2nd gen iPad Pro (2017) vs my 2013 second hand i7 rMBP did the same task with same performance. I wonder if the 2020 iPad Pro is slightly faster.

In my win98se qemu vm, fifa 99 runs slightly faster than fifa 98, which is feeling almost like a stop motion game - I must double check if I am not missing any setting. GP3 also struggles a bit.

Lets see if I can get qemu patched in a linux distro...

i guess on mac pro you should be able to use
qemu.exe -accel hvf

robertmo wrote on 2020-09-01, 00:50:

i guess on mac pro you should be able to use
qemu.exe -accel hvf

Yup, I did it for XP last weekend. But a QEMU machine without Direct3D will not work. HVF does not work for 98SE vm, it crashes before loading the OS. HVF does work for XP and 7 but still no D3D. I never managed to do W10 and I don’t really care about that terrible version of Windows with telemetry and data collection buried inside...

Hence why I tested dosbox-x, it had 3dfx/voodoo, I did a stellar install without much hassle for 9x, but even before installing any game I felt it was slower than qemu, because I loaded Netscape 9.0.0.6 to download some drivers and it took ages to load. On my vmware version, same OS and same browser, its faster, much faster.

I don’t know what to do next.

To @kjliew: I know you will be thinking about dropping macOS Support (God help us) but here's some food for thought to consider in the future. I found it inside the Apple Developer Documentation regarding porting macOS apps to Apple Silicon:

If your app uses Metal, OpenGL, or OpenCL, be aware of the following differences:
The GPU and CPU on Apple silicon share memory.
OpenGL is deprecated, but is available on Apple silicon.
OpenCL is deprecated, but is available on Apple silicon when targeting the GPU. The OpenCL CPU device is not available to arm64 apps.