Though I have never used macOS systems, it is obvious to me that either you don't really understand how your "homebrew" works or your pkg-config is simply broken. There is nothing magic about pkg-config, it just needs to know where to look for *.pc files. Some pkg-config ports could be really dumb, they hard-coded the path for all the *.pc files. Some smarter pkg-config ports will use relative path and resolve the absolute path from where it was invoked and end up with *basedir*/lib/pkgconfig where all the *.pc files are stored.

QEMU configure script depends on pkg-config (typical Linux style build) to resolve the libraries dependencies. You should have checked the pkg-config sanity with

1$ pkg-config --list-all | grep -i glib
2$ pkg-config --modversion glib-2.0

If the above commands failed, then you don't have a sane build environment and you got to fix that. Using environment override "export XXX" could work sometimes, but personally I would refrain from doing so to get things going. It is an obvious indication that somethings was wrong if environment overrides are needed.

kjliew wrote on 2020-08-27, 22:48:

Though I have never used macOS systems, it is obvious to me that either you don't really understand how your "homebrew" works or […]
Show full quote

Though I have never used macOS systems, it is obvious to me that either you don't really understand how your "homebrew" works or your pkg-config is simply broken. There is nothing magic about pkg-config, it just needs to know where to look for *.pc files. Some pkg-config ports could be really dumb, they hard-coded the path for all the *.pc files. Some smarter pkg-config ports will use relative path and resolve the absolute path from where it was invoked and end up with *basedir*/lib/pkgconfig where all the *.pc files are stored.

QEMU configure script depends on pkg-config (typical Linux style build) to resolve the libraries dependencies. You should have checked the pkg-config sanity with

Copy code to clipboard

1$ pkg-config --list-all | grep -i glib
2$ pkg-config --modversion glib-2.0

If the above commands failed, then you don't have a sane build environment and you got to fix that. Using environment override "export XXX" could work sometimes, but personally I would refrain from doing so to get things going. It is an obvious indication that somethings was wrong if environment overrides are needed.

Again, thanks for your assistance. I really don't completely understand how it works, I am only a front-end web designer, much more focused on the design part than the code itself. Here's the output of these two commands:

1Last login: Thu Aug 27 18:30:28 on ttys000
2MacBruno-Pro:~ Bruninho$ pkg-config --list-all | grep -i glib
3gmodule-no-export-2.0 GModule - Dynamic module loader for GLib
4gio-unix-2.0          GIO unix specific APIs - unix specific headers for glib I/O library
5gio-2.0               GIO - glib I/O library
6gthread-2.0           GThread - Thread support for GLib
7gmodule-2.0           GModule - Dynamic module loader for GLib
8gmodule-export-2.0    GModule - Dynamic module loader for GLib
9gobject-2.0           GObject - GLib Type, Object, Parameter and Signal Library
10glib-2.0              GLib - C Utility Library
11MacBruno-Pro:~ Bruninho$ pkg-config --modversion glib-2.0
122.64.5
13MacBruno-Pro:~ Bruninho$

Cool, so your pkg-config is actually working. So what exactly was the error from running QEMU configure script?

If you still get the mismatch GLIB_SIZEOF_SIZE_T, then it means that you had problems on multi-arch where you try to build 32-bit QEMU while pointing at 64-bit headers or vice versa.

kjliew wrote on 2020-08-27, 23:37:

Cool, so your pkg-config is actually working. So what exactly was the error from running QEMU configure script?

If you still get the mismatch GLIB_SIZEOF_SIZE_T, then it means that you had problems on multi-arch where you try to build 32-bit QEMU while pointing at 64-bit headers or vice versa.

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

Basically, after checking the dependencies and installing any that were missing from homebrew (libffi, gettext, glib, pkg-config, autoconf, automake, pixman) all I had to do was follow exactly the same steps as given on your github page's simple guide.

And when I executed the last command (../qemu-4.1.1/configure && make), the error came in. the files are stored in my user folder (/Users/Bruninho/myqemu).

The error means that you had mixed up 32-bit and 64-bit arch headers/libraries, or compiler simply failed to locate the header file, which is glib.h. QEMU configure script uses "pkg-config --cflags" for the path to library header files. So if you run

1$ pkg-config --cflags glib-2.0

You should be able to figure out if there is problem with the path to header files. I guess it is very unlikely for one to mix up 32-bit vs 64-bit multi-arch headers/libraries. Whenever you got an error from configure script, you can always check the config.log to figure out the cause.

kjliew wrote on 2020-08-28, 00:54:

The error means that you had mixed up 32-bit and 64-bit arch headers/libraries, or compiler simply failed to locate the header f […]
Show full quote

The error means that you had mixed up 32-bit and 64-bit arch headers/libraries, or compiler simply failed to locate the header file, which is glib.h. QEMU configure script uses "pkg-config --cflags" for the path to library header files. So if you run

Copy code to clipboard

1$ pkg-config --cflags glib-2.0

You should be able to figure out if there is problem with the path to header files. I guess it is very unlikely for one to mix up 32-bit vs 64-bit multi-arch headers/libraries. Whenever you got an error from configure script, you can always check the config.log to figure out the cause.

OK, I don't know if it's clear, so I'm giving here the output of this command and attaching the config.log.

1MacBruno-Pro:~ Bruninho$ pkg-config --cflags glib-2.0
2-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

And from config.log, apparently stops here:

1ld: library not found for -lGLX
2clang: error: linker command failed with exit code 1 (use -v to see invocation)

Look like Apple is crippling OpenGL on macOS as Dominus had mentioned earlier. Too bad I have never played with Apple/macOS software ecosystem, I only test my code on Windows 10 and Linux. I hope you could still get GLX on macOS as I have no plan to support Apple specific GL implementation.

Oh damn. Yeah, apparently they deprecated it. But I thought that the code was still there?

https://apple.stackexchange.com/questions/379 … -catalina-10-15

I'll do some research to see if I can still get it back. If not, the plan B would be definitely an overkill: A VM with Linux, but emulation on QEMU there would probably be much more slower. Then I could repeat it with an ARM Linux distro VM on ARM Macs.

Although I personally believe that Vulkan/MoltenVK would be a much better option than OpenGL. I understand that Apple is pushing for devs to use their Metal API.

EDIT: Interesting. OpenGL is still there apparently. Chrome does use it instead of Metal. When I go to chrome://gpu on Chrome, the page reports that Chrome is indeed using OpenGL ("enabled") instead of Metal ("disabled").

So I have no idea of what is wrong there. EDIT 2: Anyway, I don't even expect OpenGL to be there on macOS Big Sur, so I might have to look elsewhere.

EDIT 3: Apparently they will still be there. https://t.co/A14sGVvzgc

The problem with OpenGL, even if it is still supported on macOS, is the GL context creation. This is platform implementation specific. The QEMU MESA GL pass-through only has the codes for WGL (Windows) and GLX (Linux). Both APIs have specific binding with the underlying display managers, WIN32 and X11. Windows was pretty standard, but in the world of Linux/BSD things are a little messy. Though X11 could be the standard in the past, this is no longer true at the onset of Wayland. Fortunately, XWayland still support GLX, so that makes things a little better but I believe the future would focus more on display-less APIs such as EGL for OpenGL context creation for portable codes without extra layer of upper level libraries such as SDL2, GTK and Cocoa. I am not familiar with Vulkan but i believe it would have taken a page from EGL to avoid any binding from display managers.

kjliew wrote on 2020-08-28, 19:50:

The problem with OpenGL, even if it is still supported on macOS, is the GL context creation. This is platform implementation specific. The QEMU MESA GL pass-through only has the codes for WGL (Windows) and GLX (Linux). Both APIs have specific binding with the underlying display managers, WIN32 and X11. Windows was pretty standard, but in the world of Linux/BSD things are a little messy. Though X11 could be the standard in the past, this is no longer true at the onset of Wayland. Fortunately, XWayland still support GLX, so that makes things a little better but I believe the future would focus more on display-less APIs such as EGL for OpenGL context creation for portable codes without extra layer of upper level libraries such as SDL2, GTK and Cocoa. I am not familiar with Vulkan but i believe it would have taken a page from EGL to avoid any binding from display managers.

Well, then there is not much hope for me on macOS. I see that DOSBox-X does have a Voodoo2/3Dfx implementation, I was even able to compile and run it on macOS, but never really tested it deeply because DOSBox-X's networking implementation on macOS does not use the Mac's wifi, only the ethernet, and the best CPU emulated there is a Pentium MMX. Probably not good enough for Grand Prix 4 with mods and season mods with high quality graphics textures for cars and tracks anyway.

I wanted a more complete solution and I thought that QEMU is the most powerful open-source solution available. Homebrew does have xquartz and glfw, and these were not of much use really unless I had the knowledge to use them.

Anyway, I will try to set up a Linux VM with VMware and try again there to see how much loss of performance QEMU will have there. If it's not as bad as it seems to be, then I might just do an ARM Linux VM on ARM Macs just for the same thing. I was going to have an ARM Linux VM there anyway, since I wanted to move my local web server stuff from macOS to a Linux VM in the future. It'll be good because when I decide to try something new, I don't risk breaking my macOS environment and I will never have to rebuild that environment again if I go to another Mac or PC; For every new computer I had, I always had to rebuild my web server from scratch, wasting a painful day of work to set up a local web development server, so a VM might just solve it for me.

EDIT: This "Plan B" is assuming that VMware remains true to their tweet where they announced that the future brand new VMware Fusion Player app would be free to use.

Grand Prix 4 is DirectX 8.1, so that would put any Voodoo/3Dfx implementation out of reach regardless of CPU. It's a really cool, realistic racing sim, by the way. With a CPU requirement of Pentium II 400MHz, no emulation would reach that level of performance without virtualization. With QEMU KVM on Ryzen 2500U APU, the game automatic graphics calibration measured 44FPS. The same setup on Core m3-6Y30 measured 28FPS. Both are significantly more powerful than typical Pentium II 400MHz systems in year 2002 when the game debut. So I doubt a real Pentium II 400MHz would get anything better than 20FPS with all the graphics bells and whistles.

Perhaps you can also consider Wine on macOS, but if you prefer the solution with VM (to prevent breaking the OS) then you can try Wine on Linux VM.

Yeah. Best I can do with is Grand Prix 3 on Windows 98. It's running somewhat good on my iPad Pro, through UTM app and Windows 98SE VM. Also, GP3 does not need 3Dfx/Voodoo.

I couldn't find a reason why on normal QEMU & my MacBook, and Win XP VM, Grand Prix 4 was giving me a black screen. I thought it probably required some sort of Voodoo/3Dfx implementation.

Thing is, I'd still need that implementation for my macOS Win 9x VMs because FIFA 98 and FIFA 99 are 3Dfx/Voodoo games and need it for reasonably better graphics. I have a Win XP VM on VMware Fusion, which has VMware SVGA 3D graphics driver, and I had installed nGlide there. Then FIFA 98 had the better higher quality graphics somehow. Also, before I did that, GP4 was running perfectly well on VMware Fusion XP VM after installing VMware Tools.

On my iPad Pro UTM Win 98 VM, FIFA 98 runs in software mod and a little bit slower (but that is a 2nd gen iPad Pro, I assume 2020 iPad Pro is 12% faster).

I tried with Wineskin Winery first on my macOS, GP4 does run, but I need the mods and editors to run too and when I use them, after the editor patches the game with a season mod (for example, 1994 season) and tries to run the game, it crashes. Something is missing for the editor to finish patching I guess.

Let's see how the Linux VM will perform.

I must be the biggest idiot in the world when I can't even manage to compile it in a Ubuntu 20.04 LTS VM....

EDIT: I decided to try again on macOS and I replaced the -lGLX on configure to -framework OpenGL and presto it started to compile. But produced 54 warnings and 3 errors and not a single executable. I stopped here:

154 warnings and 3 errors generated.
2make[1]: *** [hw/3dfx/glide2x_impl.o] Error 1
3make: *** [i386-softmmu/all] Error 2

kjliew wrote on 2020-08-28, 21:15:

Grand Prix 4 is DirectX 8.1, so that would put any Voodoo/3Dfx implementation out of reach regardless of CPU. It's a really cool, realistic racing sim, by the way. With a CPU requirement of Pentium II 400MHz, no emulation would reach that level of performance without virtualization. With QEMU KVM on Ryzen 2500U APU, the game automatic graphics calibration measured 44FPS. The same setup on Core m3-6Y30 measured 28FPS. Both are significantly more powerful than typical Pentium II 400MHz systems in year 2002 when the game debut. So I doubt a real Pentium II 400MHz would get anything better than 20FPS with all the graphics bells and whistles.

Perhaps you can also consider Wine on macOS, but if you prefer the solution with VM (to prevent breaking the OS) then you can try Wine on Linux VM.

With tweaks to f1graphics.cfg, the performance can be even better. For example, you can disable crowd camera flashes & animations, environment maps, game overlays, and Videowalls, far distance objects... and gain a lot more of fps. Some say that even setting car LODs to "0", improves it even more. Definitely a great game, I have a few mods to install spanning across 1984 and 1998 seasons as well as track packs for these seasons.

Bruninho wrote on 2020-08-29, 00:19:

EDIT: I decided to try again on macOS and I replaced the -lGLX on configure to -framework OpenGL and presto it started to compile. But produced 54 warnings and 3 errors and not a single executable. I stopped here:

Perhaps you were using clang instead of gcc. QEMU typically compiled on Linux with gcc without any warning. I did make sure that my addition of Glide and MESA GL pass-through do not introduce compilation warnings with up-to-date GNU GCC on MSYS2 and ArchLinux.

Apparently I was using clang, yes. So that was the problem? damnit...

Wait, but I followed the instructions that were on the github page.

Bruninho wrote on 2020-08-29, 20:55:

Wait, but I followed the instructions that were on the github page.

So what? Those instructions are meant to be simple. The open-source world is always biased towards GNU GCC 😀, if you had been such naive and unaware of the fact... Support for clang is just around the corner recently due to popularity by Apple and Google. I just tried the latest clang on ArchLinux to build QEMU-5.1.0. It failed at the codes from mainline which I didn't touch. So that's about it, you could file a bug to QEMU, but I don't really care.

Ok, now I need to figure out how to do that without clang...

kjliew wrote on 2020-08-29, 07:48:

Perhaps you were using clang instead of gcc. QEMU typically compiled on Linux with gcc without any warning. I did make sure that my addition of Glide and MESA GL pass-through do not introduce compilation warnings with up-to-date GNU GCC on MSYS2 and ArchLinux.

I managed to compile both QEMU 4.1.1 (the one used in your github page) and 5.1.0 from source and using Apple's default clang on macOS without your patch, all working OK. So the problem must be in the way the patch is applied for macOS version, then.

So, from your page, the instructions are:

1Simple guide to apply the patch:
2(using 10-qemu411-mesa-glide.patch)
3
4$ mkdir myqemu && cd myqemu
5$ git clone https://github.com/kjliew/qemu-3dfx.git
6$ cd qemu-3dfx
7$ wget https://download.qemu.org/qemu-4.1.1.tar.xz
8$ tar xf qemu-4.1.1.tar.xz
9$ cd qemu-4.1.1
10$ rsync -r ../qemu-0/hw/3dfx ./hw/
11$ rsync -r ../qemu-1/hw/mesa ./hw/
12$ patch -p0 -i ../10-qemu411-mesa-glide.patch
13$ mkdir ../build && cd ../build
14$ ../qemu-4.1.1/configure && make

Please just assume that I am not experienced enough in this subject and also please point out what am I doing wrong then?

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