configuring xcode’s clang to compile using a given c++ standard


I’ve been working with C++ lately, particularly the compilers that support the latest C++ standards such as C++11, C++14, C++17, and C++2a (the upcoming C++20 which should be finally published sometime in February). Rather than install gcc/g++ via Brew on my Mac, I’ve been endeavoring to learn how to compile against those standards using Apple’s clang/clang++ compilers.

The unfortunate part for me (at first) was what command line switches needed to be passed to clang to enable the ability to compile a given standard’s code. I was able to determine what those switches were by deliberately mangling a switch in a makefile and then running make. For my troubles I got the following helpful list:

note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard
note: use 'c++11' for 'ISO C++ 2011 with amendments' standard
note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard
note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard
note: use 'c++17' for 'ISO C++ 2017 with amendments' standard
note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard
note: use 'c++2a' for 'Working draft for ISO C++ 2020' standard
note: use 'gnu++2a' for 'Working draft for ISO C++ 2020 with GNU extensions' standard

For example, to compile against C++17, you would use

clang++ --std=c++17 ...

to enable compilation of source code that uses features from C++17 on back. This keeps the tool clutter down on my Mac, which was getting a bit out of hand with the various GCC compilers via Brew. The GCC tools are all very good, but I would rather use clang since it’s delivered by Apple and is a part of the Xcode tool suite available to every Apple user. As of this point in time the Xcode version is 12.1.2 and clang’s version is 11.0.0. One final note, gcc is linked to clang and g++ is linked to clang++.

manjaro linux 18.1 – not ready for virtualization prime time

I read of a new group selling Linux computers, Tuxedo Computers (https://www.tuxedocomputers.com), which is bundling Manjaro Linux with the hardware. All the commentary about Manjaro is laudatory, especially when running on the Tuxedo hardware. So I navigated over to the Manjaro Linux site (https://manjaro.org) and downloaded the latest ISO release, 8.1.

I run a number of Linux systems virtually using Oracle’s VirtualBox on my Mac, all successfully. Before installing a Manjaro guest VM, I updated to the latest VirtualBox, 6.1.2. The update was no problem with my existing VMs, which are a mix of RHEL/CentOS/Oracle Linux 8.1 releases, and various Debian/Ubuntu VMs as well. I was able to update the guest extensions on all of them with no issues whatsoever. Keep that in mind.

Installation of Manjaro was absolutely smooth with no issues. It was attempting to install the guest extensions in the VM where I ran into issues. I tried the regular way of installing them by mounting the extensions CD image and running the installation script. I installed the minimal image, which meant I had to install the kernel header files matching my kernel, gcc, and make. I then ran the installation script and had no failures. On reboot unfortunately the extension that enabled folder sharing of the host’s filesystem failed. The dmesg error indicated a lack of kernel symbols. I then went looking in the Arch Linux forums (Manjaro is based on Arch) and discovered there was an Arch package with those extensions pre-built. Fine. I uninstalled the extensions I installed, then installed using pacman. On reboot the extension still failed to load because the module “taints the kernel”. The message is part of the screen capture at the top of the post.

I won’t put up with this. I would love to run this distribution because its tools are up to the very latest (gcc and Python in particular), and the kernel is the near-latest version 5.4. There’s an awful lot to like about this distribution. But this problem with the VirtualBox kernel modules, especially ones provided via pacman, is a show stopper for me. I need the ability to share files between my VMs and my Mac, or between VMs using the Mac shared folder. That feature works like a charm with every distribution I have except for Arch in general, and this version of Manjaro.

There’s also one other aggravation with Arch/Manjaro I really don’t care for, and that’s the attitude that crops up in the forums, and is exemplified by the comment “that’s not the way we do things in Arch.” Fine. It wouldn’t be such a big deal if it all worked without drama, but it doesn’t. And I’ve already had my run-ins with Arch on my Raspberry Pi (3 and 4) systems as well as an attempt in times past to just get an Arch VM running. The Raspberry Pi installations eventually all failed to properly update after a time, and the VM never worked, including the VirtualBox shared filesystem module.

In April Ubuntu 20.04 will be released with the latest kernel and tools, and I’ll step up to that and call it a day. If I need to keep on the bleeding edge, there’s always the non-LTS Ubuntu releases as well, and there are also ways to keep a Debian installation on leading release tools. I don’t need Manjaro and the Arch attitude that comes with being derived from Arch. All the other distros Just Work. In the future when my clients ask what Linux distribution to install and run, Manjaro won’t be one that I recommend.

I might be retired but I still do a bit of consulting.