Recent sView 20.08 release includes macOS builds – again after a three years break of macOS support. Release promises support of OS X 10.10 and later, but several users have reported a very strange thing – macOS 10.13 and 10.14 declined to start an application indicating that sView requires macOS 10.15 or later for unknown reason…

This error has deeply puzzled me, as I have personally installed sView on OS X 10.10 without any errors – an older macOS version than reported by users. A nonsense I would say!

You can launch Minecraft on Mac OS X 10.5 or later. The Minecraft installer is commonly called minecraft.dmg. The actual developer of this software for Mac is Mojang. Minecraft for Mac is included in Games. Free download MindChimes Demo MindChimes Demo for Mac OS X. MindChimes Demo - This app is a computer companion that runs in the background while you use your computer for other tasks and will not interfere with the operation of any of your software.

Let’s come back to sView release history to see what changed. There was a reason for a long three years break – my mid-2010 MacBook with an ancient, utterly slow Core2Duo processor and slow mobile hard-drive became nothing but a piece of room’s furniture. Hardware was slow from the very beginning (I had to upgrade RAM from 2 GiB to 8 GiB right after taking the MacBook), but nowadays it is just unbearable.

Since it’s very first release on this platform and until 17.04 release, sView supported OS X 10.6 (Snow Leopard) and any later versions of the system. Supporting old OS versions might be challenging and could be decoupled into two steps:

1. Availability of an older OS.
2. An SDK targeting an older OS.

Old device at hand

First point is very important, because without an older OS at hand, an application developer relies on a blind assumption that a building toolchain does everything right. But practice shows numerous hidden compatibility issues breaking this assumption as a tiny glass. Such issues might happen on any target OS, including Windows, Linux and Android.

To keep older OS available for testing, a developer has to be careful with system updates and care on some old devices, as in many cases installing an old OS version on a brand-new device shipped with the most recent OS version – this is especially related to rolling-style system updates practiced for macOS. Yearly rolling updates give users new features and improvements, but also bring instability, compatibility and usability issues annoying conservative users.

The first problem becomes more desperate in case of macOS due to limited access to OS installation images and poor virtualization capabilities for running macOS as a guest system.

SDK targeting an older OS X

Second point is more flexible – technically, it is possible to build an application on a newer OS version targeting an older one. In the past, this usually meant using a toolchain with an OS SDK of minimal version – older XCode releases came with several OS X SDKs at once.

Building against a specific SDK version by default defines a minimum OS version that application could be used. Even if an application doesn’t use any new OS features, there is no guarantee that some implicit dependencies will not occur.

In practice, however, restrictions appeared very soon – newer XCode versions required newer OS X versions to start and also left behind older SDKs, at the same time older XCode versions declined to work properly on newer OS X versions!

To overcome these issues, sView development environment has been configured on OS X 10.6 Snow Leopard with help of dual-boot setup for a newer OS X version for regular use. This configuration served well for many years with seldom issues building newer FFmpeg versions using an old GCC toolchain. But as has been mentioned at the beginning of the article, old hardware made it unreliable today.

It’s true that Apple and other OS vendors push hard users and developers towards regular updates and usage of only the most recent version(s) of their OS, making older releases outdated quite fast. However, problems of backward compatibility still bothers OS developers. Building toolchains shipping several OS SDKs in the past have been mutated into toolchains shipping the single most recent OS SDK, but has modified it to be able to target earlier versions as well.

So that focus has changed – developer uses as most recent SDK version as possible, and just configures building toolchain to target a minimal OS version application should run onto. In case of macOS this could be:

• MACOSX_DEPLOYMENT_TARGET environment variable
  (e.g. export MACOSX_DEPLOYMENT_TARGET=10.10);
• -mmacosx-version-min compiler flag
  (e.g. EXTRA_CXXFLAGS += -mmacosx-version-min=10.10).

CMake has a similar alias variable CMAKE_OSX_DEPLOYMENT and qmake has QMAKE_MACOSX_DEPLOYMENT_TARGET variable for the same purpose. If you are using XCode directly, you can find an appropriate option deep inside project building properties.

Sounds simple enough, but a lot of questions come to my mind: what is the minimal OS version supported by a specific version of XCode (project settings allows selecting 10.6, but building fails until 10.7+ is specified instead)? What is the reasonable minimal OS version to target? How to ensure that application dependencies target the same minimum? How to verify that application actually starts? What system will show to the user in case of an issue?

After lurking into macOS release history, I have chosen OS X 10.10 Yosemite to be a bare minimum – released almost 6 years ago and 5 versions behind the most recent update macOS 10.15 Catalina. Sounds like a good basis – it is difficult to imagine a user working on an older release considering an aggressive Apple update policy and that many popular applications require even newer macOS versions. And OS X 10.10 has been already installed on my old MacBook – too old for development, but still alive for testing purposes.

Interesting to note – while looking for macOS 10.14 Mojave, I have realized that this release does not support my old mid-2010 MacBook (photo below is from the Internet – mine doesn’t look that good nowadays), and the latest compatible version is macOS 10.13 High Sierra released in ‘2017. So that Apple has supported device with OS updates just around 7 years.

Deal is done – Makefile in sView project has been updated to target 10.10 by aforementioned parameters (as well as FFmpeg building scripts), Info.plist has been updated to set LSMinimumSystemVersion=10.10, build was done on macOS 10.15 installed on a fresh MacMini (6 Intel CPU cores, but just 8 GiB of RAM and a small-capacity drive!) and tested on OS X 10.10 installed on an ancient MacBook. Looks perfect!

Minos mystery

And then, users suddenly tell me that sView fails to start on macOS versions newer than tested one with an error indicating macOS 10.15 as a minimal supported version. Nonsense! Where did the system even take this “10.15” from, if LSMinimumSystemVersion clearly specifies “10.10” – the way OS X used to show such error messages before?

Digging the neighborhood, I’ve been finally able to find some device with macOS 10.13 showing the same error. Unbelievably, running sView executable directly from the Terminal started just fine without any error! Looking around with the application package didn’t help to identify a place, where the system finds “10.15” from, but finally I have concluded that it is somewhere inside sView executable itself!

Playing with “otool -l” revealed the truth:

Gotcha! Looking around the Internet didn’t reveal much information about “minos” information in a Mach-O executable header, but I have observed that this property is relatively new. This answers the question – how is it possible that an older OS X 10.10 was able start sView, while newer macOS 10.13-10.14 were unable? OS X 10.10 just knows nothing about “minos”.

One question remained opened – what should be fixed? Analysing the sView package, I have realized that “minos” occurs only in sView shared libraries and executable, while FFmpeg built using the very same toolchain was clean from it. So that there was definitely something wrong in a Makefile, and after some tryouts it was identified that -mmacosx-version-min option was specified only to compiler via EXTRA_CXXFLAGS, but not to linker. Adding the option to EXTRA_LDFLAGS has finally solved the problem:

Question or issue on macOS:

I get gdb by brew install gdb.

The source file content is:

Here is the executable file named 'demo':
https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw

I compile the source file like this:

And run gdb

But, it can't work. It can't recognized the executable file.

I use file demo,its ouput is demo: Mach-O 64-bit executable x86_64

I use file ./demo,its output is ./demo: Mach-O 64-bit executable x86_64

Type c++ -v, output is :

run ./demo,its output is 55
type show configuration in gdb,it shows:

Who can help me ? Thank you very much !!!

How to solve this problem?

Solution no. 1:

The problem is that clang-1000.11.45.2 distributed with Apple LLVM version 10.0.0 add a new load command to o-mach executables named LC_BUILD_VERSION.

From the apple source:

So currently bfd (program used by gdb to manipulate executables) is not able to interpret this command, and returns the error.

The temporary solution I found is directly edit bfd sources provide with gdb.
I've only test with gdb-8.0.1.

First, download gdb-8.0.1 sources from mirrors. Then add to gdb-8.0.1/bfd/mach-o.c the following code at line 4649 :

And finally add int gdb-8.0.1/include/mach-o/loader.h :

at line 189 (don't forget to add a , at the end of the line 188 after BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).

After these instructions you can follow a classic gdb compilation as indicate inside the README :

Don't forget to sign gdb as explain here.
If you still get the (os/kern) failure (0x5) error, just run sudo gdb.

This is a temporary solution waiting for the GNU team fix the problem directly on the repo.

EDIT

Binutils-gdb has been updated, these changes are now implemented in commit fc7b364.

Hope It will be helpfull.

Solution no. 2:

I published a temporary brew formula that seems to work, while awaiting for official brew formula to be updated:

brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb

Solution no. 3:

Upgrade to GDB version 8.3. Also see Issue 23728, binutils fail on macOS 10.14 (Mojave) due to unimpl in the Binutils bug tracker.

From the bug report:

I've found the root of the issue. binutils does not handle load
command 0x32 LC_BUILD_VERSION (nor 0x31 LC_NOTE, actually). They are
defined in recent LLVM versions: see
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77
Looking at the output of objdump -private-headers there is one clear
difference:
@@ -56,16 +56,18 @@ attributes NO_TOC STRIP_STATIC_SYMS LIVE
reserved1 0
reserved2 0
Load command 1
- cmd LC_VERSION_MIN_MACOSX
- cmdsize 16
- version 10.13
- sdk n/a
+ cmd LC_BUILD_VERSION
+ cmdsize 24
+ platform macos
+ sdk n/a
+ minos 10.14
+ ntools 0
Load command 2
cmd LC_SYMTAB
cmdsize 24

LC_VERSION_MIN_MACOSX is implemented in binutils, while
LC_BUILD_VERSION is not. It is apparently new in Mojave.

Solution no. 4:

I have got a good solution for me from stack overflow and I do not know why it works.
Here is the link.

I am new to macOS, and I do the following:

1. Codesign gdb 8.0.1 in high Sierra
2. Update to Mojave
3. gdb 8.0.1 died with BFD: /Users/xxx/Codes/demo: unknown load command 0x32
4. Change to gdb 8.2.1 and come across Keychain error Unknown Error -2,147,414,007.
   

   Solve this by getting the certificate in Login then export it and import it into System(Delete it from Login if unable to import).

5. Finally, because of some kind of errors it still does not work and it comes with ERROR: Unable to start debugging. Unexpected GDB output from command '-exec-run'. Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8)), according to how to undo codesign, something wrong still exist and the answer tells me to brew reinstall gdb, but it still does not work, I called it a day yesterday.
6. Finally I come across that link, I AM HAPPYY, now I am able to debug!

Hope my solution can help.

Solution no. 5:

I got gdb working on Mojave by:

a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.

Minos (demo) Mac Os 11

b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.

c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html

Voila.

(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)

Solution no. 6:

gdb 8.2 installed from Homebrew is not compatible with Mac mojave.
I have upgrade to 8.2.1. The issue should be resolved.

Mac Os Versions

Solution no. 7:

The answer by timotheecour above did work for me:

brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb

Then I had to generate a generate a self-signed certificate as in
https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/

Solution no. 8:

I got past this issue on Mojave by thinning the app. GDB does not understand universal binaries. So if file myapp tells you myapp is a universal binary, try this:

And then

Hope this helps!