mosh 1.3.2_4 doesn't build with clang >= 7.0

[lemzwerg (Werner Lemberg)]

macports-ports 617c6a370ac0d457baffa8d66a5df5471a921907
macOS 10.7.5 11G63
Xcode 4.6.3 4H1503

Log file is attached.

[lemzwerg (Werner Lemberg)]

build log of mosh 1.3.2_4 on MacOS 10.7.5

[quentinmit (Quentin Smith)]

I don't have access to a Lion machine so I'm not sure how to debug this. It looks like... the C++ standard library is trying to include a file called version and is finding the file called VERSION in mosh's root directory (because the filesystem is not case-sensitive), which contains "mosh 1.3.2" (because it's not a C++ header, it's just a text file for humans).

384	:info:build In file included from /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/cstddef:38:
385	:info:build ../../version:1:1: error: In file included from hostinput.pb.cc:4unknown type name 'mosh'
386	:info:build mosh 1.3.2

Presumably the C++ includes also have a file called version? I don't know why the mosh root directory is even in the include path, much less why it's being preferred over the correct file.

[kencu (Ken)]

built for me on 10.6.8 without any intervention...clang-5.0/libc++

mosh @1.3.2_4+perl5_26 (active) platform='darwin 10' archs='x86_64' date='2019-07-03T16:09:54-0700'

[kencu (Ken)]

Hmmm. Look also at this comment 57751#comment:9 that looks related. In that case, the file VERSION was simply deleted prior to the build.

It looks like clang-7.0 and up have an include file named version -- probably not a perfect name as it's so generic.

$ port contents clang-8.0 | grep version
  /opt/local/libexec/llvm-8.0/include/c++/v1/__libcpp_version
  /opt/local/libexec/llvm-8.0/include/c++/v1/version
  /opt/local/libexec/llvm-8.0/lib/c++/v1/__libcpp_version
  /opt/local/libexec/llvm-8.0/lib/c++/v1/version
$ port contents clang-7.0 | grep version
  /opt/local/libexec/llvm-7.0/include/c++/v1/__libcpp_version
  /opt/local/libexec/llvm-7.0/include/c++/v1/version
  /opt/local/libexec/llvm-7.0/lib/c++/v1/__libcpp_version
  /opt/local/libexec/llvm-7.0/lib/c++/v1/version
$ port contents clang-6.0 | grep version
  /opt/local/libexec/llvm-6.0/include/c++/v1/__libcpp_version
  /opt/local/libexec/llvm-6.0/lib/c++/v1/__libcpp_version

[quentinmit (Quentin Smith)]

I asked my neighborhood Clang developer. They told me that the version include is part of the C++20 standard. If we built with -Wnonportable-include-path -Wnonportable-system-include-path then clang would at least emit a better warning about the filename not matching, but there's currently no clang flag that will cause it to ignore the file named VERSION and continue looking for a file called version.

Do we have a sense for how widespread this is? So far we have mosh and qt4-mac affected; are there many other packages? (Seems likely, since "VERSION" is a super common filename?)

[lemzwerg (Werner Lemberg)]

Uh, oh, to add such a common name to the C++ standard as an include header file name really, really hurts :-|

And yes, a VERSION file is extremely widespread. On my computer alone I count more than 20 projects that have it, including GNU groff and LilyPond (which are both C++ applications). My own ttfautohint program has it, too...

[quentinmit (Quentin Smith)]

For Mosh this won't be a trivial workaround, even. The VERSION file is actually used as part of the build process, so I can't just remove it before starting the build. Fixing it would require a sizable patch to Makefile.am and Makefile.in (is there a standard for that in MacPorts - should I patch both files? Only Makefile.am and rerun automake? Only Makefile.in?).

[quentinmit (Quentin Smith)]

I filed ​https://bugs.llvm.org/show_bug.cgi?id=42540 upstream, let's see if they have any miraculous advice.

[quentinmit (Quentin Smith)]

LLVM upstream is looking for some data about how widespread this is; do we have any way of telling using MacPorts? I'm guessing nothing regularly tries to build packages with clang >= 7.0, right?

[kencu (Ken)]

that's right. We'll only start to see this in bulk when that becomes the default for Xcode's clang version.

[quentinmit (Quentin Smith)]

I opened ​https://github.com/macports/macports-ports/pull/4799 with a workaround patch from upstream. Still doesn't do anything to solve the general problem other ports will experience.

I ran some quick numbers against Debian since they have an index of every package's source files and found:

227 Debian buster source packages contain a file named "version", and a further 991 Debian buster source packages contain a file named "VERSION" or a different mixed case. (This is only packages that ship the file directly in their source; some packages also generate these files at build time and would not be counted in this.)

Of the 1218 Debian source packages that contain a file named "version" (with some case), 392 contain C++ code by file extension (".cpp", ".c++", ".C", etc.). Of *those* 217 are definitely affected because they have a "config.h" in their root directory, plus some number of the remainder whose include path is not so easily determined from a file listing.

So it's quite possible we have dozens or even a hundred packages that are similarly impacted by this bug.

[kencu (Ken)]

It looks like all the actively developed ones will need a fix like this from upstream. Yuk. All the rest will have to have the VERSION file deleted, or otherwise be tweaked by us.

Luckily, all the buildbots are actually on VMs with case sensitive file systems I believe, so we may squeak by with many builds that way....

[kencu (Ken)]

if you ask me, they should rename the include to __version right now, update clang 7 and 8, and gcc if needed, and fix this for everyone now...

[quentinmit (Quentin Smith)]

In 70ca3f65e622c17582fd938602d800157ed951c3/macports-ports (master):

mosh: Support building with C++20 (clang 7+ and GCC 9.1+)

mosh, like many autoconf-based packages, has a file called "VERSION"
in its workdir. C++20 now tries to include that file as the upstream
header "version".

This takes an upstream patch from
​https://github.com/mobile-shell/mosh/pull/1052 which works around the
issue by moving config.h and version.h into a subdirectory.

Fixes: #58690