Our CI is designed for one-formula-per-PR, unfortunately.

Would you mind splitting your PR?

To add some context to this, it looks like something has changed in Big Sur (believe this is not Apple Silicon specific) where packages that use uses_from_macos "ncurses" are breaking. Explicitly configuring the package to use ncurses seems to resolve the issue.

I'm no expert in this, but I think maybe packages are looking for curses (which is usually pointed to ncurses) rather than ncurses and are now failing? That's the conclusion I came to anyway, at least we know how to roughly fix this issue

Our CI is designed for one-formula-per-PR, unfortunately.

Would you mind splitting your PR?

Oh sorry I created a branch from a branch I was working on already rather than master! I'll force push and remove that erroneous commit

Explicitly configuring the package to use ncurses seems to resolve the issue.

I’d rather we figure out exactly why this is happening and see if a common fix in brew can be applied.

The OpenSSL pkg-config change shouldn’t be required either.

I’d rather we figure out exactly why this is happening and see if a common fix in brew can be applied.

I have had a poke with other formulas that also use uses_from_macos "ncurses" and there doesn't seem to be any rhyme or reason why this happening yet and I've only found two instances of this happening. In fact a lot of packages that use ncurses like this work fine - htop for example.

As uses_from_macos "ncurses" is being defined in the formula already, I don't see being explicit about configuring packages being a problem as it doesn't break them on previous macOS versions either.

For now I would say just patching the formula is fine as a fix for the time spent and the impact of this issue. The reason I could think of is what I mentioned previously, but there is no supporting information for this from what I can find. If it becomes a huge issue, then it may be worth investigating the time to find out what is causing it.

The OpenSSL pkg-config change shouldn’t be required either.

I didn't require this locally, but it was required to get the checks to pass on this PR @claui found this (I'm not exactly sure why this happens) #57871 (comment)

I’d rather we figure out exactly why this is happening and see if a common fix in brew can be applied.

After a couple of debug printouts in configure, I think I’m figuring out what’s happening here.

In line 18945, configure compiles a set of probes in a loop in order to check whether the compiler can find various curses headers:

#line 18946 "configure"
#include "confdefs.h"
#include <${cf_header}>
int
main (void)
{
initscr(); tgoto("?", 0,0)
  ;
  return 0;
}

But the probe no longer compiles on macOS 11.0, even though the curses headers are there:

configure:18951:12: error: implicit declaration of function 'tgoto' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
initscr(); tgoto("?", 0,0)
           ^
1 error generated.

The compile failure then sets off a false alarm, and configure erroneously assumes there are no curses headers.

I didn't require this locally, but it was required to get the checks to pass on this PR @claui found this (I'm not exactly sure why this happens) #57871 (comment)

PKG_CONFIG is supposed to point to the pkg-config binary so all that is currently doing is preventing pkg-config from being used. If you want that then you might as well do --with-pkg-config=no.

Not entirely sure why it's being baked in the binary. I'll poke around.

@claui Ah yes, tgoto is in term.h/termcap.h. Might be worth reporting that bug. I'm fine with the --with-screen in the meantime then.

For the shim thing try --disable-config-info. The default behaviour seems to be to copy the configure output into the binary for debugging purposes.

For the shim thing try --disable-config-info. The default behaviour seems to be to copy the configure output into the binary for debugging purposes.

@Bo98 Thanks, will give that a go 🙂 Should we leave a comment in the Formula pointing to this PR for future reference regarding the ncurses issue I case we ever find a proper fix / reason for the change in behaviour?

Sure, might as well.

Looks like this works now 🎉

Thanks!