Opened 3 days ago

Last modified 17 hours ago

#66765 assigned defect

ncurses error: unknown type name 'SCREEN'

Reported by: vigna (Sebastiano Vigna) Owned by: herbygillot (Herby Gillot)
Priority: Normal Milestone:
Component: ports Version: 2.8.0
Keywords: Cc: jmroot (Joshua Root), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Port: ncurses

Description

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.

Attachments (1)

main.log (1.3 MB) - added by vigna (Sebastiano Vigna) 3 days ago.
log

Download all attachments as: .zip

Change History (18)

Changed 3 days ago by vigna (Sebastiano Vigna)

Attachment: main.log added

log

comment:1 Changed 3 days ago by ryandesign (Ryan Schmidt)

Keywords: ventura added
Owner: set to herbygillot
Port: starship added
Status: newassigned
Summary: starship cannot be installedstarship @1.12.0: error: unknown type name 'SCREEN'
Version: 2.8.0

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:                                                               ^

comment:2 Changed 3 days ago by 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

comment:3 Changed 3 days ago by kencu (Ken)

Cc: jmroot MarcusCalhoun-Lopez added

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.

comment:4 Changed 2 days ago by vigna (Sebastiano Vigna)

Any workaround you can suggest?

comment:5 Changed 44 hours ago by 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

Last edited 44 hours ago by kencu (Ken) (previous) (diff)

comment:6 Changed 44 hours ago by vigna (Sebastiano Vigna)

OK, and how would I do that? 😅

comment:7 Changed 44 hours ago by kencu (Ken)

added the details above for you: :>

comment:8 Changed 44 hours ago by vigna (Sebastiano Vigna)

Kludge approved! 🙏🏻

comment:9 Changed 43 hours ago by 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.

comment:10 Changed 42 hours ago by 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.

comment:11 Changed 29 hours ago by 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.

comment:12 Changed 20 hours ago by 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.

Last edited 20 hours ago by kencu (Ken) (previous) (diff)

comment:13 Changed 19 hours ago by 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.

comment:14 Changed 18 hours ago by kencu (Ken)

Keywords: ventura removed
Port: ncurses added; starship removed
Summary: starship @1.12.0: error: unknown type name 'SCREEN'ncurses error: unknown type name 'SCREEN'

comment:15 Changed 18 hours ago by jmroot (Joshua Root)

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

comment:16 Changed 17 hours ago by 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);
                                                              ^
Last edited 17 hours ago by kencu (Ken) (previous) (diff)

comment:17 Changed 17 hours ago by 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.

Note: See TracTickets for help on using tickets.