starship @1.12.0: error: unknown type name 'SCREEN'

[vigna (Sebastiano Vigna)]

MacBook Pro, M1 Max Mac OS 13.2 (22D49) XCode Version 14.2 (14C18) MacPorts 2.8.0

"port install starship" dies with the attached log.

[vigna (Sebastiano Vigna)]

log

[ryandesign (Ryan Carsten Schmidt)]

Looks like a problem with include paths, because bits of macOS ncurses are trying to include bits of MacPorts ncurses and they're evidently not compatible:

:info:build warning: In file included from <module-includes>:477:
:info:build warning: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/ncurses.h:141:
:info:build warning: /opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'
:info:build warning: NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
:info:build warning:                                                               ^

[kencu (Ken)]

when the module.map workaround was removed from the ncurses port recently, I wondered if we might start seeing this old headache again.

​https://github.com/macports/macports-ports/commit/28a14b0a637aa68694e30545662b2c09af683ffa

[kencu (Ken)]

Josh, do you think this is that old issue with ncurses again, after removing the module.map workaround Marcus put in a couple of years back?

I didn't look to see why it was felt that this workaround was no longer needed.

[vigna (Sebastiano Vigna)]

Any workaround you can suggest?

[kencu (Ken)]

probably try putting the previous module.map workaround back in, and see if it fixes it.

ie put this file in /opt/local/include

​https://github.com/macports/macports-ports/blob/0c1afe696461721e33ca89a6c43619ac3ff23c84/devel/ncurses/files/module.modulemap

[vigna (Sebastiano Vigna)]

OK, and how would I do that? 😅

[kencu (Ken)]

added the details above for you: :>

[vigna (Sebastiano Vigna)]

Kludge approved! 🙏🏻

[kencu (Ken)]

don't forget to remove it again after you've built your thing. Having personally-installed files in the macports repo will generate troubles in the longer term. I suspect Josh and Marcus will take another look at this soon enough.

[kencu (Ken)]

The basic issue here is that when using modules, the standard include paths are not followed as expected, so the wrong headers are found.

[jmroot (Joshua Root)]

I couldn't get it to break with a simple test program using modules. If someone could come up with a minimal test case that reproduces the problem, that would be immensely helpful in investigating and reporting the issue to Apple and llvm.org.

[kencu (Ken)]

I talked to Jeremy about this two or three years ago, and discussed it with llvm.

At least one engineer was working on modules.

llvm said modules were still pretty new and they didn't know what to do about it at that time...If I looked long enough I could probably find the email I sent to the clang-dev mailing list.

[kencu (Ken)]

Here's one simple reproducer.

% cat test.c
#include <ncurses.h>

int
main(void) {
  return (0);
}

% clang -isystem /opt/local/include  test.c
< OK >

 % clang -fmodules -isystem /opt/local/include  test.c
While building module 'Darwin' imported from /opt/local/include/curses.h:95:
In file included from <module-includes>:477:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/ncurses.h:141:
/opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                                              ^
/opt/local/include/unctrl.h:61:53: error: function cannot return function type 'char *(int *, chtype)' (aka 'char *(int *, unsigned int)')
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                                    ^
/opt/local/include/unctrl.h:61:54: error: a parameter list without types is only allowed in a function definition
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                                     ^
In file included from test.c:1:
/opt/local/include/curses.h:95:10: fatal error: could not build module 'Darwin'
#include <stdint.h>
 ~~~~~~~~^
4 errors generated.

you get a lot more errors if it is run as "test.m" by the way.

[jmroot (Joshua Root)]

Interesting. That appears to be the opposite of the problem in this ticket; any idea how to make that one happen?

[kencu (Ken)]

Looks like the same problem to me -- different SDK, otherwise same.

ticket:

In file included from <module-includes>:477:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/ncurses.h:141:
/opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);

reproducer:

In file included from <module-includes>:477:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/ncurses.h:141:
/opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                                              ^

[kencu (Ken)]

why this issue only seems to show up with ncurses is a good question.

When the module map workaround was added specific to ncurses I expected to see a whole slew more similar header conflicts crop up.

But none ever seemed to -- just ncurses. Perhaps it is the most sensitive, due that SCREEN header change they did between v5 and v6 that sticks out.

Usually we'd see wreckage with libiconv etc -- but no, just ncurses... so far.

[wyuenho (Jimmy Yuen Ho Wong)]

Is this the same issue as #59992?

Can we put the modulemap back? Why was it removed? There's no explanation in the commit about this at all.

[kencu (Ken)]

in the end we will put it back, as there are no other viable options.

we’re just waiting for that shoe to drop.

[jmroot (Joshua Root)]

In f226dfef5ad1c349549ec0f4cf90e3f6d039b6df/macports-ports (master):

starship: workaround -fmodules error

See: #66765

[herbygillot (Herby Gillot)]

starship has been updated to 1.13.1. In addition to jmroot's module fix above, can those affected confirm whether or not they're still experiencing issues?

[vigna (Sebastiano Vigna)]

I installed the modulemap back when it was suggested, and 1.13.1 compiled without problems.

[dancorne (Dan Corne)]

I had this issue too and worked around it by manually adding a module.modulemap file as described above. I've now removed that file and installing starship 1.13.1 works as expected, thanks!

[vigna (Sebastiano Vigna)]

Ok, I removed it too. It installed the binary without problems, but from sources it didn't work. Log attached.

[vigna (Sebastiano Vigna)]

Log