Unable to compile daily build in macOS 10.14

[almeath]

In macOS 10.14 Mojave, I am unable to compile daily builds of ScummVM from the Github repository. I would be interested in knowing if anyone else is experiencing the same problem.

The terminal output is as follows:


Creating config.h
Creating config.mk
Creating engines/engines.mk
Creating engines/plugins_table.h
192-168-1-1:scummvm almeath$ make bundle
C++ backends/platform/sdl/sdl.o
In file included from backends/platform/sdl/sdl.cpp:25:
In file included from ./backends/platform/sdl/sdl.h:26:
In file included from ./backends/platform/sdl/sdl-sys.h:147:
/opt/local/include/SDL/SDL_syswm.h:58:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
^~~~~~~~~~~~
1 error generated.
make: *** [backends/platform/sdl/sdl.o] Error 1
192-168-1-1:scummvm almeath$

[criezy]

I have installed yesterday Mojave on my secondary computer to do some tests, but have not started doing those yet.
However I suspect the issue you see is not specific with Mojave.

By default SDL configure will enable both the Cocoa and X11 backend on macOS.
However (for a while now) XQuartz (the X11 component for macOS) is not installed by default.

Did you compile SDL after installing Mojave or was it already there before, maybe compiled with X11 support, which is no longer present?
Or it could be that it is not looking at the X11 headers in the right place. If I remember XQuartz install them in /opt/X11 and it may be looking for them somewhere else.

You can get and install XQuartz from xquartz.org.

Or you could recompile SDL without X11 support (which is what I always do). I don't remember the exact configure option, but you can run configure --help to find it.

If that does not help can you indicate what you get when running /opt/local/bin/sdl2-config --cflags ?

[tsoliman]

I've had Mojave for a few days now. It compiles no problem but then there's the "black screen" bug from SDL2 (and SDL1 is completely busted) .. had to compile the latest SDL2 "tip" to get it to work.

So once you fix the build errors, you're going to run into the black screen until you upgrade SDL2 to a newer release than 2.0.8 (that is unreleased yet) or compile the latest SDL2 yourself.

Note that all of this doesn't affect running all binaries in Mojave, just ones that were built using Mojave, if that makes sense. (it only affects people who compile their own ScummVM)

[almeath]

Thank you both for the advice.

Yes, I have no trouble running ScummVM binaries in Mojave that I compiled earlier in High Sierra. These issues only affect fresh compiles after I upgraded to Mojave.

My installs of SDL1 and 2 have been on my system going back to macOS 10.12 and earlier. Likewise, I installed XQuartz as far back as 10.9.

I will try the manual compile and reinstall of SDL2, without X11 support, and see how that goes.

[almeath]

It has been a while since I looked at this, but I recently upgraded my Mac and I can no longer boot back into High Sierra to do manual ScummVM compiles.

I started by re-installing Mojave, followed by a clean install of Homebrew (and all supporting ScummVM libraries). I also reinstalled the latest SDL, Xcode command line tools and XQuartz for good measure. So this is basically a 'clean' system.

At first it gave the exact same error as last year, about not locating the X11 files. I then looked in opt/local/include and saw that there is an X11 folder in there containing the Xlib.h file that cannot be located when running the ScummVM compile.

So, I copied that entire X11 folder (containing Xlib.h) and placed it inside opt/local/SDL.

This time, the make command seemed to trigger the normal build process and all was going well with the outputs in terminal.

However, right at the end it fails at the last hurdle, with this output:

LINK scummvm
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
Common::Encoding::convertIconv(char const*, char const*, char const*, unsigned long) in libcommon.a(encoding.o)
"_iconv_close", referenced from:
Common::Encoding::convertIconv(char const*, char const*, char const*, unsigned long) in libcommon.a(encoding.o)
"_iconv_open", referenced from:
Common::Encoding::convertIconv(char const*, char const*, char const*, unsigned long) in libcommon.a(encoding.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: *** [scummvm] Error 1

[criezy]

That is a strange one. I just tried a compilation on my macOS 10.14.5 system and it worked without issues.
I have no idea what could be causing this on your side, but you should be able to bypass the issue by using --disable-iconv in your configure options.

[almeath]

I have no idea what could be causing this on your side, but you should be able to bypass the issue by using --disable-iconv in your configure options.

Thanks for that suggestion - that got it to compile successfully.

Whilst I did migrate my account over to my new Mac, I had thought that a fresh install of the OS along with Xcode and Homebrew would flush out any legacy issues. Perhaps I was wrong. I will see if can compile on another Mac with Mojave to test this further.

[criezy]

I think I found and fixed the issue that caused the undefined symbols related to iconv (there was an issue when fluidsynth is not enabled). So hopefully you should now be able to compile without having to specify --disable-iconv.

[almeath]

Thanks for taking the time to investigate this issue. I can confirm that the changes you made have resolved the problem. I have no problems compiling with the standard settings in Mojave 10.14.6.