When using curses, look for libterminfo as well.

[0-wiz-0]

Description

fish uses the cur_term symbol itself. On NetBSD (which has its own curses implementation) this is provided by libterminfo. The curses checks already look for libtinfo, extend this to look in libterminfo as well.

Fixes build failures like this:

[116/118] Linking CXX executable fish_key_reader
FAILED: fish_key_reader 
: && /scratch/shells/fish/work/.cwrapper/bin/c++ -O2 -g -fPIC -D_FORTIFY_SOURCE=2 -fstack-clash-protection -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.11 -fpermissive -Wredundant-move -g -DNDEBUG -lexecinfo -Wl,-zrelro -Wl,-znow -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib CMakeFiles/fish_key_reader.dir/src/fish_key_reader.cpp.o CMakeFiles/fish_key_reader.dir/src/print_help.cpp.o -o fish_key_reader  libfishlib.a  /usr/lib/libcurses.so  -pthread  /usr/pkg/lib/libpcre2-32.so  /usr/pkg/lib/libintl.so && :
ld: libfishlib.a(env_dispatch.cpp.o): undefined reference to symbol 'cur_term'
ld: /usr/lib/libterminfo.so.2: error adding symbols: DSO missing from command line

[mqudsi]

Please mention NetBSD here, so we aren't wondering down the line if this was in error or is no longer applicable.

Perhaps "On NetBSD, libtinfo has a longer name (libterminfo)"

(also it's libtinfo that has the longer name, and libterminfo is that longer name)

[0-wiz-0]

Thanks for the review, I've updated the comment as suggested!

[mqudsi]

Sorry I didn't catch this earlier, but this block should be in the else() for if (CURSES_TINFO) so that we aren't checking if we already found libtinfo.

[0-wiz-0]

Adapted, anything else?

[mqudsi]

If you've tested it and it still works on NetBSD with these changes then I think it LGTM.

[0-wiz-0]

I think it's correct, but building git head currently fails for me with:

  --- stderr

  CXX include path:
    /archive/foreign/fish-shell-fork/a/./cargo/build/x86_64-unknown-netbsd/release/build/fish-rust-5ad3fdfa44e675d2/out/cxxbridge/include
    /archive/foreign/fish-shell-fork/a/./cargo/build/x86_64-unknown-netbsd/release/build/fish-rust-5ad3fdfa44e675d2/out/cxxbridge/crate
  /archive/foreign/fish-shell-fork/fish-rust/../src/proc.h:101:23: error: static assertion expression is not an integral constant expression
  /archive/foreign/fish-shell-fork/fish-rust/../src/proc.h:101:23: note: cast from 'void *' is not allowed in a constant expression
  Error: 
    × the include_cpp! macro couldn't be expanded into Rust bindings to C++:
    │ Bindgen was unable to generate the initial .rs bindings for this file.
    │ This may indicate a parsing problem with the C++ headers.

[faho]

/archive/foreign/fish-shell-fork/fish-rust/../src/proc.h:101:23: note: cast from 'void *' is not allowed in a constant expression

That's some awkward static_assert:

fish-shell/src/proc.h

Line 101 in dec3976

static_assert(WIFEXITED(zerocode), "Synthetic exit status not reported as exited");

It can just be removed. Tho I have no idea why that would fail for you, or why it would fail now - that hasn't changed in 4 years. Possibly corrosion/cxx weirdness.

[mqudsi]

Yeah, master is in a state of flux as we are midway through a port to rust.

I'll tag your change for 3.6.2 which is a hypothetical patch release of the latest C++ version. You can check out LastC++11 and apply your patch against it to build the latest locally, if you like.

[mqudsi]

Yeah, I get similar but different hard errors that prevent me from compiling on an old macOS install because autocxx apparently consumes headers with -Wall -Wextra or something.