almeath wrote on 2021-01-23, 12:46:

.. and I had success with the following terminal command: […]
Show full quote

.. and I had success with the following terminal command:

CXXFLAGS="-std=c++11" make

There is just one error now, which is preventing a successful compile. It cannot find the file sdk2_glide.h.

I tried installing glide via Homebrew, but that has not helped.

So close! ...

Copy code to clipboard

1g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE  -std=c++11 -MT glide.o -MD -MP -MF .deps/glide.Tpo -c -o glide.o glide.cpp
2In file included from glide.cpp:23:
3../../include/glide.h:64:10: fatal error: 'sdk2_glide.h' file not found
4#include <sdk2_glide.h>

Great! Did you re-run configure?
You can also try to check where that sdk2_glide.h file resides on your filesystem. If it's nowhere to be seen, maybe you're just missing a dev package for Glide (on Ubuntu the package would probably be something like glide-dev)?
Btw I wonder which Glide version that would be. There's MacGlide (seems old) and maybe OpenGlide works too..or maybe something entirely different

mr.cat wrote on 2021-01-23, 13:24:

Great! Did you re-run configure?
You can also try to check where that sdk2_glide.h file resides on your filesystem. If it's nowhere to be seen, maybe you're just missing a dev package for Glide?
Btw I wonder which Glide version that would be. There's MacGlide (seems old) and maybe OpenGlide works too..or maybe something entirely different

Yes, tried that and got the same error as above.

So far, all I know is that even after running brew install glide I do not end up with a file called 'sdk2_glide.h' anywhere on my drive.

I will need to read up on glide for the Mac and see what I can find out..

EDIT: I found OpenGlide here:

https://github.com/voyageur/openglide

It only has platform references for Windows and Linux, but at least that means a Unix friendly build could be possible for macOS. It contains the file 'sdk2_glide'.

Now to figure out how to install it..

EDIT 2: I tried copying the following files from the OpenGlide folder directly into the include folder:

sdk2_3dfx.h
sdk2_glide.h
sdk2_glidesys.h
sdk2_glideutl.h
sdk2_sst1vid.h

But now that generates another error:

1g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE  -g -O2 -mno-ms-bitfields  -MT glide.o -MD -MP -MF .deps/glide.Tpo -c -o glide.o glide.cpp
2glide.cpp:165:21: error: no member named 'info' in 'SDL_SysWMinfo'
3        hwnd = (HostPt)wmi.info.x11.window;
4                       ~~~ ^
5glide.cpp:390:15: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
6                while(pfile = readdir(pdir)) {
7                      ~~~~~~^~~~~~~~~~~~~~~
8glide.cpp:390:15: note: place parentheses around the assignment to silence this warning
9                while(pfile = readdir(pdir)) {
10                            ^
11                      (                    )
12glide.cpp:390:15: note: use '==' to turn this assignment into an equality comparison
13                while(pfile = readdir(pdir)) {
14                            ^
15                            ==
16glide.cpp:1017:63: warning: format specifies type 'int' but the argument has type 'Bitu' (aka 'unsigned long') [-Wformat]
17            LOG_MSG("Glide:Invalid buffer passed in grLfbLock (%d)", buffer);
18                                                               ~~    ^~~~~~
19                                                               %lu
202 warnings and 1 error generated.

I guess just placing those files in the include folder is not the way to do it..

It seems that there are multiple new projects that have adopted the "glide" name and these are unrelated to the 3dfx api...rather unfortunate..
Maybe your "brew install glide" gave you one of these. There's at least something Go-related by that name.

OpenGlide is the one we use on Linux, but I don't know if it is the best one to use for macOS (or if it works at all). In any case you need to compile it, the header files won't work without the libraries present.

Thanks, I will try to figure out if this openglide repistory will compile for macOS. No sign of how to generate a make file or autogen etc, but I will investigate.

I also realized that 'glide' in Homebrew has absolutely nothing to do with the glide API for 3D acceleration so that is a dead end.

I guess I could see if ECE will compile without Glide support, but that would kind of defeat the purpose of what I am doing.

almeath wrote on 2021-01-23, 13:45:

I guess just placing those files in the include folder is not the way to do it..

Definitely not, openglide is a library like libsdl, libpng. It needs to be compiled and installed into a prefix (could use one just for openglide but then you need to point the Cflags and LDflags additionally to that prefix). So best risk it and install it into the brew prefix. Depending on how your system is set up, you might just need to run "make install" (after a successful make).
Openglide needed some macOS fixes last time I tried which was ages ago but can be found in these forums.

OpenGlide converts the Glide calls to OpenGL, and Apple has deprecated macOS OpenGL support. It is permanently stuck at OpenGL 4.1. Not sure what OpenGL version OpenGlide actually needs.

If OpenGlide needs a newer OpenGL version, solutions may be to look for a glide lib that converts directly to Apple Metal (I don't think it exists), or use a OpenGL to Metal wrapper such that you would have Glide -> OpenGL -> Metal.

AFAIK Openglide is an ancient thing that is ok with the deprecated OpenGL version provided by macOS (again some fixes were needed ages ago). Unless development picked up again in the last few years

The deprecated MacOS OpenGL was stuck at OpenGL 2.1. OpenGlide is mostly OpenGL 1.1 + a few optional extensions if they are available. MacGLide is the fork of OpenGlide for past MacOS. I am not sure if it still works today on MacOS.

AFAICS, MacGlide never came to OS X.

almeath wrote on 2021-01-23, 12:46:

.. and I had success with the following terminal command:

CXXFLAGS="-std=c++11" make

Don't just use that. You are getting an unoptimized result that will run very slow. Use "-std=c++11 -O3".

realnc wrote on 2021-01-23, 20:28:

Don't just use that. You are getting an unoptimized result that will run very slow. Use "-std=c++11 -O3".

Thanks - that works too - up to the point of the glide related error.

1hwnd = (HostPt)wmi.info.x11.window

You need to fix this for your SDL 2.0 native window handling. Isn't X11 deprecated on MacOS?

kjliew wrote on 2021-01-24, 00:35:

You need to fix this for your SDL 2.0 native window handling. Isn't X11 deprecated on MacOS? […]
Show full quote

Copy code to clipboard

1hwnd = (HostPt)wmi.info.x11.window

You need to fix this for your SDL 2.0 native window handling. Isn't X11 deprecated on MacOS?

The error mentioning the x11.window only resulted from placing the various ".h" files from the openglide-master folder straight into the DOSBox build folder. According to Dominus, I need to first successfully make/install the libraries on my system. The original error of the missing sdk file is therefore the primary issue at the moment...

So far, I am stalled on trying to work out how to install openglide when there is no autogen or configure. It just contains a make.am and configure.ac, and I am still investigating how to handle that on a Mac. The platform sub-folder only contains Windows and Linux folders, as well as "dosbox" and "dosemu" incidentally.

https://github.com/voyageur/openglide

I doubt I can advance further until I find a way to get this installed into my user/local folder along with all my other modules.

I am not fluent at MacOS ecosystem. There are a few problems that may raise the issues on MacOS. Someone more fluent with MacOS ecosystem should answer them

The source of OpenGlide that you just referred has 3 native window support, SDL1.2, X11 and Win32. Typical build would default to SDL1.2. Isn't SDL1.2 deprecated on latest MacOS, too? Can you build vanilla DOSBox SVN instead of jumping right at the DOSBox ECE? There is an adaptation of SDL2.0 for DOSBox. It is available as patch and I am not sure if DOSBox ECE already incorporated it. The build error that you have is from Gulikoza's glide patch. It is strictly SDL1.2 if untouched and expects the interface to access native window handle through SDL1.2.

Or, you could remove Gulikoza's glide patch. The Voodoo chip emulation implementation does not require OpenGlide, hence has no need to pass native window handle from DOSBox into external glide wrapper for rendering.

kjliew wrote on 2021-01-24, 02:02:

I am not fluent at MacOS ecosystem. There are a few problems that may raise the issues on MacOS. Someone more fluent with MacOS ecosystem should answer them

The source of OpenGlide that you just referred has 3 native window support, SDL1.2, X11 and Win32. Typical build would default to SDL1.2. Isn't SDL1.2 deprecated on latest MacOS, too? Can you build vanilla DOSBox SVN instead of jumping right at the DOSBox ECE? There is an adaptation of SDL2.0 for DOSBox. It is available as patch and I am not sure if DOSBox ECE already incorporated it. The build error that you have is from Gulikoza's glide patch. It is strictly SDL1.2 if untouched and expects the interface to access native window handle through SDL1.2.

Or, you could remove Gulikoza's glide patch. The Voodoo chip emulation implementation does not require OpenGlide, hence has no need to pass native window handle from DOSBox into external glide wrapper for rendering.

Both OpenGL and SDL1.2 are deprecated on the mac. OpenGL is at 4.1, which is high enough to hardly ever cause major problems. I have separately installed both SDL1 and 2 via Homebrew, and keep each up to date. I have successfully used SDL1.2.x (Mercurial) to compile SVN, tested as of yesterday with release 4420.

Yes, it seems there are some complex issues surrounding Glide on macOS and it may take some time to resolve, if at all. Rather than continue to fill up this thread with Mac-specific compiliation problems, I would be happy to get ECE built without the Glide patch, as it is not the primary reason I want to use the build. If I can subsequently figure out the Glide issues, I will he happy to circle back here to report on the outcome.

The last thing I need some guidance on here would be how to remove the Glide patch before compilation.. I am not sure what steps are required for that.

almeath wrote on 2021-01-24, 01:04:

So far, I am stalled on trying to work out how to install openglide when there is no autogen or configure. It just contains a make.am and configure.ac, and I am still investigating how to handle that on a Mac. The platform sub-folder only contains Windows and Linux folders, as well as "dosbox" and "dosemu" incidentally.

https://github.com/voyageur/openglide

I doubt I can advance further until I find a way to get this installed into my user/local folder along with all my other modules.

It uses bootstrap. So run "./bootstrap" and it will generate a configure file to use.

SDL 1.2 is not deprecated *on* macOS. It's mainly deprecated for all platforms 😀 But the developers add fixes (for example for compiling and using SDL 1.2 on the latest macOS on ARM) and it seems they are preparing a new release of it atm.

Dominus wrote on 2021-01-24, 09:27:

It uses bootstrap. So run "./bootstrap" and it will generate a configure file to use.

Ahh, thanks for that. It will now configure properly, but running make results in yet another error now:

1/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
2Making all in platform
3Making all in linux
4/bin/sh ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../..  -I../.. -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -I/usr/include  -g -O2 -D__unix__ -D__linux__ -I../../platform/linux -MT clock.lo -MD -MP -MF .deps/clock.Tpo -c -o clock.lo clock.cpp
5libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -I/usr/include -g -O2 -D__unix__ -D__linux__ -I../../platform/linux -MT clock.lo -MD -MP -MF .deps/clock.Tpo -c clock.cpp  -fno-common -DPIC -o .libs/clock.o
6In file included from clock.cpp:14:
7In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdio.h:102:
8/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:241:12: fatal error: 'features.h'
9      file not found
10#  include <features.h>
11           ^~~~~~~~~~~~
121 error generated.
13make[3]: *** [clock.lo] Error 1
14make[2]: *** [all-recursive] Error 1
15make[1]: *** [all-recursive] Error 1
16make: *** [all] Error 2

One step forward, two steps back, as they say ..

Quick test reveals I have the same problem. It did work apparently when I built it ten years ago 😀

GCC vs clang?

I can confirm that "<features.h>" exists on mingw-w64 GCC 10.2. Perhaps you could check out whatever latest GCC available from the homebrew. Or, you could remove the line "#include <features.h>" or simply touch a dummy "features.h" in the compiler's header files search path to see if anyone really use it. Sometimes, the symbols or declarations are already there in other included header files for a different compiler from GCC.

I saw that a new build (4425) has been compiled

Something must have gone wrong with the upload, unfortunately: all three r4425 archives show up as zero-bytes in size