Ticket #18675 (closed defect: fixed)
ncursesw 5.7 hangs on distroot for arch ppc64
| Reported by: | anthony.c.smith@… | Owned by: | mcalhoun@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.8.0 |
| Keywords: | Cc: | ||
| Port: | ncursesw |
Description
When installing a 4-way universal build distroot hangs on ppc64 with the message:
You may see messages regarding extended capabilities, e.g., AX. These are extended terminal capabilities which are compiled using
tic -x
If you have ncurses 4.2 applications, you should read the INSTALL document, and install the terminfo without the -x option.
Built using Intel (Core 2 Duo)/Leopard using MacPorts r47435.
Bug report #18187 claims to fix this issue in r47312 but I am continuing to have the problem.
Command used: sudo port -v install ncursesw +universal
Change History
comment:1 in reply to: ↑ description Changed 4 years ago by mcalhoun@…
- Owner changed from macports-tickets@… to mcalhoun@…
comment:2 Changed 4 years ago by anthony.c.smith@…
Just tried to build with r47439 with no luck. Still stalling in the same spot.
Thanks for the quick turnaround.
comment:3 Changed 4 years ago by mcalhoun@…
I do not think the change has propagated to the rsync server yet.
Could you try again after "port cat ncursesw" reflects the change?
comment:4 follow-up: ↓ 5 Changed 4 years ago by anthony.c.smith@…
Sorry, I didn't realize I needed to wait for it to propagate. How long should the propagation take?
comment:5 in reply to: ↑ 4 Changed 4 years ago by mcalhoun@…
Replying to anthony.c.smith@…:
Sorry, I didn't realize I needed to wait for it to propagate. How long should the propagation take?
I am not sure of the setup, but based on my own experience, it can take anywhere from a few minutes to over an hour.
I just checked, and the update seems to have made it to the rsync server.
comment:6 follow-up: ↓ 7 Changed 4 years ago by anthony.c.smith@…
That did it. The issue is fixed.
Thanks for getting this resolved quickly. I was expecting to spend the next week on it.
comment:7 in reply to: ↑ 6 Changed 4 years ago by mcalhoun@…
- Status changed from new to closed
- Resolution set to fixed
Replying to anthony.c.smith@…:
That did it. The issue is fixed.
Thanks for getting this resolved quickly. I was expecting to spend the next week on it.
Glad it works.
Thanks for the report and testing.
Replying to anthony.c.smith@…:
It turns out the claim was a little premature.
The problem was that in the destroot phase, a script looks for the program tic.
When not cross-compiling, it finds the version that was just build.
When cross-compiling, the script is smart enough not to try and instead finds /usr/bin/tic, which hangs.
#18187 claimed to fix the problem because, on the test machine, there was a previously installed ${prefix}/bin/tic which got the job done.
r47439 is an attempt to fix the problem.
Please let me know if it works.