Opened 14 months ago

Last modified 13 months ago

#66765 assigned defect

starship @1.12.0: 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), dancorne (Dan Corne), wyuenho (Jimmy Yuen Ho Wong)
Port: starship

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 (2)

main.log (1.3 MB) - added by vigna (Sebastiano Vigna) 14 months ago.
log
main.2.log (780.3 KB) - added by vigna (Sebastiano Vigna) 13 months ago.
Log

Change History (29)

Changed 14 months ago by vigna (Sebastiano Vigna)

Attachment: main.log added

log

comment:1 Changed 14 months ago by ryandesign (Ryan Carsten 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 14 months 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 14 months 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 14 months ago by vigna (Sebastiano Vigna)

Any workaround you can suggest?

comment:5 Changed 14 months ago by kencu (Ken)

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

Version 0, edited 14 months ago by kencu (Ken) (next)

comment:6 Changed 14 months ago by vigna (Sebastiano Vigna)

OK, and how would I do that? 😅

comment:7 Changed 14 months ago by kencu (Ken)

added the details above for you: :>

comment:8 Changed 14 months ago by vigna (Sebastiano Vigna)

Kludge approved! 🙏🏻

comment:9 Changed 14 months 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 14 months 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 14 months 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 14 months 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 14 months ago by kencu (Ken) (previous) (diff)

comment:13 Changed 14 months 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 14 months 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 14 months 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 14 months 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 14 months ago by kencu (Ken) (previous) (diff)

comment:17 Changed 14 months 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.

comment:18 Changed 14 months ago by dancorne (Dan Corne)

Cc: dancorne added

comment:19 Changed 14 months ago by wyuenho (Jimmy Yuen Ho Wong)

Cc: wyuenho added

comment:20 Changed 14 months ago by 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.

comment:21 Changed 14 months ago by 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.

comment:22 Changed 13 months ago by jmroot (Joshua Root)

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

comment:23 Changed 13 months ago by jmroot (Joshua Root)

In f226dfef5ad1c349549ec0f4cf90e3f6d039b6df/macports-ports (master):

starship: workaround -fmodules error

See: #66765

comment:24 Changed 13 months ago by 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?

comment:25 Changed 13 months ago by vigna (Sebastiano Vigna)

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

comment:26 Changed 13 months ago by 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!

comment:27 Changed 13 months ago by vigna (Sebastiano Vigna)

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

Changed 13 months ago by vigna (Sebastiano Vigna)

Attachment: main.2.log added

Log

Note: See TracTickets for help on using tickets.