'make -C mail/neomutt build' fails with an undefined symbol [[1]] in the ncurses port is installed on FreeBSD 12.4.  This is a new change between neomutt-20230407 and neomutt-20230512.

The key is this addition:

--- work/neomutt-20230407/gui/mutt_curses.h     2023-04-07 08:00:22.000000000 -0600
+++ work/neomutt-20230512/gui/mutt_curses.h     2023-05-12 05:31:15.000000000 -0600
@@ -37,6 +37,12 @@
 #include <curses.h>
 #endif

+#if (((NCURSES_VERSION_MAJOR > 6) ||                                           \
+      ((NCURSES_VERSION_MAJOR == 6) && (NCURSES_VERSION_MINOR >= 1))) &&       \
+     defined(NCURSES_EXT_COLORS))
+#define NEOMUTT_DIRECT_COLORS
+#endif
+


If it detects ncurses 6.x it uses "direct colors" which now calls init_extended_pair() as of neomut-20230512.  That function is not in ncurses 5 which is the base ncurses library in 12.4

Here is what's happening - the build uses the ncurses header file from ports (in /usr/local/include) but links with the ncurses lib from base (in /usr/lib).

13.2 has ncurses 6 in /usr/lib and has the missing symbol from ncurses 5, so it does not have this failure.  However, it is still including the header from /usr/local and linking with the library in /usr/lib. It's just luck if it does not fail to compile with headers from /usr/local and link with the lib from /usr/lib.  There could be failures at run time if it DOES build and potential build failures as the ports and base ncurses diverge in the future.

[[1]] linker error:

cc -o neomutt alternates.o commands.o conststrings.o copy.o editmsg.o  enriched.o external.o flags.o functions.o git_ver.o globals.o  handler.o hdrline.o help.o hook.o init.o keymap.o mailcap.o  maillist.o main.o muttlib.o mutt_account.o mutt_body.o  mutt_config.o mutt_header.o mutt_history.o mutt_logging.o  mutt_mailbox.o mutt_signal.o mutt_socket.o mutt_thread.o  mview.o mx.o opcodes.o recvcmd.o resize.o rfc3676.o  score.o sort.o status.o subjectrx.o system.o version.o libindex.a libpager.a  libpop.a  libbrowser.a libcompmbox.a libstore.a  libprogress.a libquestion.a libpostpone.a libalias.a libsend.a  libconvert.a libcompose.a libattach.a libgui.a libenter.a libcomplete.a libnntp.a  libpattern.a libmenu.a libcolor.a libenvelope.a   libhelpbar.a libmbox.a libnotmuch.a libmaildir.a  libncrypt.a libimap.a libconn.a libhcache.a   libsidebar.a libbcache.a libhistory.a  libcore.a libparse.a libconfig.a libemail.a libaddress.a   libmutt.a -Wl,-rpath,/usr/local/lib:/usr/local/lib  -Wl,-rpath=/usr/local/lib -fstack-protector-strong  -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/local/lib:/usr/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib -fstack-protector-strong -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err  -lz -ltinfow -lnotmuch -L/usr/local/lib -lgpgme  -lgpg-error  -lsasl2  -lintl -liconv -lssl -lcrypto  -lidn2  -lpcre2-8  -llmdb  -ltokyocabinet -lbz2 -lz -lrt -lpthread -lm -lc
ld: error: undefined symbol: init_extended_pair
>>> referenced by curses.c
>>>               curses.o:(curses_color_new) in archive libcolor.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Note: In the cases where the link succeeds (e.g., on 12.x without the ncurses port installed or on 13.x), the linker line does not reference libncurses (or libncursesw), and yet the neomutt binary is dynamically linked with libncursesw.so.  So it's getting pulled into the linked binary implicitly somewhere.