[Solved] What breaks LEDE builds under macOS 10.13?

For Developers
1

I have been building LEDE targets for a long time under macOS 10.11 and 10.12.

Now I am trying to get the build (lede 17.01.4) work again under 10.13, but am failing at very basic levels, that is already while building the host tools.

What happens is that host binaries are built that immediately crash with "illegal instruction". when called (m4, bison, see below).

I know that the compiler has changed with XCode 9, and I've seen that there were XCode 9 related fixes on October 5th by Felix Fietkau, but these seem to apply to XCode 9 on 10.12 only, and not 10.13. But this means that the XCode 9 compiler as such can't be the problem by itself, but something in the 10.13 environment.

Unfortunately, my understanding of the build system and autotools is not firm enough yet to have the slightest clue how it is possible at all that such defective binaries are created without any warning or error while building, and where and how to start looking for a solution.

This is on a completely fresh LEDE 17.01.4 checkout into a empty directory:

make (world) proceeds through building m4 without error, but when a subsequent package uses that m4, it fails, because then the call to m4 crashes.

I then symlinked the system's working /usr/bin/m4 as a q&d hack to get past that point.

But the same happens with bison, which also builds a binary, but then fails because it uses its own binary to put the version into docs:

src/bison --version >doc/bison.help.tmp
bash: line 1: 75006 Illegal instruction: 4  src/bison --version > doc/bison.help.tmp

Note that many other host tools build and run fine (e.g. flock, sed, patch, tar, flex).

There must be something in 10.13 that causes autotools to create broken config/build options in some cases.

Any idea?

2

Solved!

After spending the better part of a day on this looking at the wrong place (for a LEDE build system specific cause), it turned out to be a generic issue of older gnulib on macOS 10.13, as used by both m4 and bison, see the original bug report and this stackoverflow answer:

10.13's vasnprintf() intentionally crashes the executable when it is called with a format string containing %n located in writable memory, because that is a potential attack vector, and the older gnulib use it that way.

gnulib was fixed in July with two patches (first, second) in the maint branch.

m4 and bison however still use the older gnulib.

I combined these two patches into one, and added it as 101-gnulib-port-to-macos-10.13.patch to the affected m4 and bison packages. A patch that applies these patches to the current lede-17.01 tree for now is here. I'll try my luck to make a PR out of it...

3

That could have been much easier, if I had searched further into the past in the LEDE master branch :wink: :

25c045763a (tools: patch various gnu tools for macOS 10.13)

But that patch was not picked for lede-17.01 so far.