Wandering in the Mojave with JavaScript

We had set out upon a journey to uprade our laptop to MacOS Mojave on a Monday. The weather stayed fine all day, and there was none of the scorching heat nor wind that one would expect from such a place. For the most part, it went largely without incident.

After the migration, I reinstalled nvm. It graciously preserved the state of my version installs; I flushed and reinstalled each them out of caution. The new binaries worked effortlessly.

I smile. This will be easy.

Okay, So It’s Not So Easy

On Wednesday, as I surmount what seems an innocuous dune of npm installs, my steed stumbles during a build of function-name.

> function-name@1.0.0 install /Users/dfoley/REDACTED/node_modules/function-name
> node-gyp rebuild

  CXX(target) Release/obj.target/binding/src/binding.o
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the
      command line to use the libc++ standard library instead
      [-Wstdlibcxx-not-found]
In file included from ../src/binding.cc:1:
/Users/dfoley/.node-gyp/6.14.4/include/node/v8.h:21:10: fatal error: 'utility'
      file not found
#include <utility>
         ^~~~~~~~~
1 warning and 1 error generated.
make: *** [Release/obj.target/binding/src/binding.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/nvm/versions/node/v6.14.4/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:219:12)
gyp ERR! System Darwin 18.2.0
gyp ERR! command "/usr/local/nvm/versions/node/v6.14.4/bin/node" "/usr/local/nvm/versions/node/v6.14.4/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/dfoley/REDACTED/node_modules/function-name
gyp ERR! node -v v6.14.4
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok

A Turn Down the Include Path

“Ah,” I thought, and mopped my brow.

include path for stdlibc++ headers not found

An Apple Developer Forums post calls attention to the fact that Xcode has deprecated libstdc++ support. The Xcode 10 Release Notes clearly state;

Building with libstdc++ was deprecated with Xcode 8 …

Libgcc is obsoleted.

A shocking development. The Forums post speaks of back-copying filesets from Xcode 9. Perhaps the situation is indeed that dire? In due time, we come upon a Github Issue which seems to bare a rich vein of information to help us in making our escape.

First, it recommends the usual unboxing for a fresh Xcode installation;

# "You must agree to both license agreements below in order to use Xcode."
sudo xcodebuild -license

# install command-line tools
xcode-select --install

In addition, the Github Issue references those same Release Notes;

some software may fail to build correctly against the SDK and require macOS headers to be installed in the base system under /usr/include …

We must perform some additional unboxing;

# install the legacy macOS headers
#   "In a future release, this package will no longer be provided."
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

# make sure that you're using the intended version of the command line tools
xcode select -s /Library/Developer/CommandLineTools

Clearly, others have taken this path when they suddenly can’t compile C program on a Mac after upgrade to Mojave and their efforts are met with success. Yet, with all our might, we cannot wrest ourselves from this pit of function-name despair.

> function-name@1.0.0 install /Users/dfoley/REDACTED/node_modules/function-name
> node-gyp rebuild

# ...

gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2

Night is falling, and we are far too exposed to the elements here. There is an encampment less than 10 kilometers to the southeast. We could reach it safely, but time is of the essence.

Certainly, this path leads us nowhere.

Pursuing Another Target

A further scroll through the Github Issue and we come across;

Hi, I got to the bottom of this issue, in the end, after a trawl through clang, distutils and python make/config files.

“Hi” indeed, Mr. Savior! At last, a solution! Let us roll up our sleeves and give it a shot;

export MACOSX_DEPLOYMENT_TARGET=10.9
export CMAKE_OSX_DEPLOYMENT_TARGET=10.9

Alas, what is good for a python in the desert is of no service to us in our function-name predicament.

> function-name@1.0.0 install /Users/dfoley/REDACTED/node_modules/function-name
> node-gyp rebuild

# ...

gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2

I must accept the fact that this Github Issue can take us no further. We must be done with it, and move on.

The Scent of Brew on the Air

The last of the daylight is fading. Venus hangs a brief ten degrees to the right of the crescent moon. I take in this truly serene and beautiful sight, though it cannot soothe the panic which has begun to rise in my stomach.

More searching unearths another Git Issue which shows promise.

I had to install g++8.2 separately.

Now there’s a fine idea. Turns out there’s some good documentation on the C++ Standard Libraries in Homebrew. Though we could call out a specific version, like gcc@7, we’ll just install the latest;

brew install gcc
brew list gcc  # aaaaand what did we get?

Tremendous! We got gcc-8.2, and with those paths, we have some compiler environment variables to set:

export CC=/usr/local/Cellar/gcc/8.2.0/bin/gcc-8
export CXX=/usr/local/Cellar/gcc/8.2.0/bin/g++-8

Yes, it’s our good old friends CC and CXX. So good to see them out in such an arid environment. They work virtually everywhere.

And that’s why we have standards & conventions, kids.

And, what of our function-name?

> function-name@1.0.0 install /Users/dfoley/REDACTED/node_modules/function-name
> node-gyp rebuild

# ...
# some 'note:'s
# some 'warning:'s
#
# until eventually
# ...

redacted@3.1.4 /Users/dfoley/REDACTED
`-- function-name@1.0.0

Our Journey Continues

Our concerns have been addressed with a brew-installed version of gcc.

Freed at last, we quickly shake the sand from our boots and set off to the southeast. There can be no doubt that we will sleep deeply tonight.

Now, won’t you please join me as our desertadventure continues with Wandering in the Mojave with Ruby …

NOTE: If your screen reader is reading this, please contact me at admin@cantremember.com ... because it shouldn't. FIXME: build this dynamically based upon the maximum content in any sub-Element of this Element. I will call this my "Safari Reader Counterweight". In some of my Posts, I have huge code excerpts, etc. Safari Reader, at least in iOS, will identify the 'main Element', the one it features, based upon its content length. Sometimes those code excerpts get identified as the 'main Element', and the Post is borked in Safari Reader mode. This is a counter-weight; it gives the <main> Element additional content so that it gets featured, algorithmically. Yes, it increases the payload of every page (@see FIXME above). But not by that much. Then again, this is a guess as to how much content any given Element could contain. If it's not enough, BOOM, Safari Reader looks like crap. So, here's a great article on how to enable Safari Reader on your site. It's mostly guesswork, but those guesses helped me debug this obtuse goddamn problem. Oh, and look, you can enter and exit Reader programmatically. JavaScript can fix anything. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload.