Opened 5 years ago

Closed 5 years ago

#60150 closed defect (fixed)

portgroups cargo, cargo-fetch fail to build new port topgrade

Reported by: lhaeger (Lothar Haeger) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc:
Port: topgrade

Description

I'm trying to submit a new port "topgrade" (https://github.com/macports/macports-ports/pull/6484) using the cargo portgroup, but building fails and I do find the reason (log from CI attached).

I get the exact same error when trying to build locally, but only when running

sudo port install -vst topgrade

The software builds just fine, though, when I cd into the work directory and run the build cmd from the log manually as:

cd /opt/local/var/macports/build/_Users_lhaeger_Documents_Source_macports-ports_sysutils_topgrade/topgrade/work/r-darwish-topgrade-aeb91c9
sudo cargo clean
sudo cargo build --release --frozen -v -j4"

I therefore suspect the cargo/cargo_fetch portgroups to cause the issue somehow.

Would be cool if someone knowing those portgroups could look into this and point me into the right direction.

Attachments (2)

cargo_topgrade_port_build_fail.txt (332.6 KB) - added by lhaeger (Lothar Haeger) 5 years ago.
Build fails running "sudo port install -vst"
cargo_topgrade_namual_build_success.txt (113.1 KB) - added by lhaeger (Lothar Haeger) 5 years ago.
Build succeeds running "sudo cargo build --release --frozen -v -j4"

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by lhaeger (Lothar Haeger)

Build fails running "sudo port install -vst"

Changed 5 years ago by lhaeger (Lothar Haeger)

Build succeeds running "sudo cargo build --release --frozen -v -j4"

comment:1 Changed 5 years ago by lhaeger (Lothar Haeger)

Owner: changed from MarcusCalhoun-Lopez, raimue to MarcusCalhoun-Lopez

comment:2 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Well the first error in the fail log is:

cargo:warning=In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/ncurses.h:141:
cargo:warning=/opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'

This shows you're using macOS ncurses.h but MacPorts unctrl.h. These are both headers that belong to the ncurses software but macOS and MacPorts provide different versions of that software so the headers are apparently not interchangeable. Either use all macOS ncurses headers and libraries or (ideally) use all MacPorts ncurses headers and libraries.

comment:3 in reply to:  2 Changed 5 years ago by lhaeger (Lothar Haeger)

Replying to ryandesign:

This shows you're using macOS ncurses.h but MacPorts unctrl.h. These are both headers that belong to the ncurses software but macOS and MacPorts provide different versions of that software so the headers are apparently not interchangeable. Either use all macOS ncurses headers and libraries or (ideally) use all MacPorts ncurses headers and libraries.

Thanks a lot for the hint, so I'll have to try to figure out how to force one or the other version. Any more hints on that, maybe?

comment:4 Changed 5 years ago by kencu (Ken)

you probably cannot fix this by configuring your build. If it's like the other examples we've seen of this, it has to do with clang using modules and mixing this up. We could disable screen extras in our ncurses build, but that's felt to be imperfect. We could edit the unctrl.h header and tweak in a fix, but that's inelegant. We bumped this upstream to Apple a few weeks back.

Until that gets sorted out someday, you're DOA on MacPorts ( homebrew apparently doesn't see this error, at least it is only reported on MacPorts and never there, possibly as they install headers into /usr/local and that's on the default search path.)

So, after you dig a bit, if it is modules causing the error, you won't be able to use MacPorts until it gets resolved. You can edit a quick hack into your own version of /opt/local/include/unctrl.h to fix it for yourself ( that's what I did ) pending either us tweaking ours in our ncurses build formally (unlikely) or App fixing modules (will happen, no idea when). Or perhaps the MacPorts decision to leave this will turn if it affects enough people, hard to say...

comment:5 Changed 5 years ago by kencu (Ken)

see #59992

comment:6 Changed 5 years ago by lhaeger (Lothar Haeger)

Modified the port to use the pre-built binary from upstream as a workaround until this issue is solved.

@kencu: if you see a fix being implemented, would you mind bumping this issue, just in case I miss it, please?

Last edited 5 years ago by lhaeger (Lothar Haeger) (previous) (diff)

comment:7 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Adding

compiler.cpath

seems to allow your port to build.

See https://trac.macports.org/ticket/59992#comment:20 for an explanation.

comment:8 Changed 5 years ago by kencu (Ken)

if you clear compiler.cpath, are the headers in /opt/local being used at all? If not, then we should clear the libs in /opt/local too, as you wouldn't want those to be used. . (which, in effect, is not using MacPorts at all, I guess).

comment:9 in reply to:  8 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Replying to kencu:

if you clear compiler.cpath, are the headers in /opt/local being used at all? If not, then we should clear the libs in /opt/local too, as you wouldn't want those to be used. . (which, in effect, is not using MacPorts at all, I guess).

Fair point.
For the sake of completeness, it might be better to add

compiler.cpath
compiler.library_path

Since this port has no non-build MacPorts dependencies, I do not think this is a problem.

comment:10 Changed 5 years ago by kencu (Ken)

yes, disabling all macports includes and libraries might work for this one port. or perhaps another at some point.

However, the others mentioned in the other ticket, like clang-devel, not so lucky. they need macports libraries.

so far, the only example of an error when mixing headers is ncurses. If we tweak our unctrl.h, that buys us time for upstream to roll out a proper clang fix eventually.

So that is why I am advocating for that rather than disabling macports libraries and includes.

comment:11 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

We have found a workaround for this particular port.
We have an open ticket to track the fundamental issue.
Any solution we settle on can easily be incorporated into topgrade without even a rebuild.

I will therefore merge PR 6484, close this ticket, and continue the discussion on the parent ticket.

Note: See TracTickets for help on using tickets.