Closed martinvonz closed 3 years ago
This patch surprises me because we are supposed to be building our own ncurses for macOS and not relying on the system library!
However, both /usr/lib/libedit.3.dylib
and /usr/lib/libncurses.5.4.dylib
are annotated as allowed libraries in the Rust validation code. They are likely listed because something is referencing them.
Either we should be linking against the system libraries and not building libedit/ncurses or we should be building these libraries and not linking against the system libraries. More investigation is needed.
Ahh - I think the root cause is macOS linker arguments are referencing -lncurses
instead of -lncursesw
. I'd say this was an oversight from 102fb0d029e902c1568c8fa0c2b9c927801c9069. However, that commit explicitly says we purposefully link against the system ncurses on macOS.
So I guess we have a choice: drop libedit/ncurses from our macOS builds or prevent linking against the system variants.
I think 07a9f2272cfb21909f270a6ae2a355505148afbb will fix this by removing the modern ncurses from the macOS build.
I'm open to using a modern ncurses and libedit on macOS. But since the system libraries were the intended versions in existing code, I decided to preserve that behavior for the time being.
I built Mercurial on Mac with PyOxidizer. I then ran
hg commit -i
and quit without changing anything. That resulted in a segfault. It seems that the issue is an ABI compatibility between the ncurses version compiled against (6.1 or 6.2, I don't remember which) and the version dynamically linked on macOS. On Big Sur, the ncurses version seems to be 5.4. Adding--with-abi-version=5
to theconfigure
script fixed the problem for me.