Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric <dim@freebsd.org> wrote:
> 
> > On 9 Oct 2021, at 15:40, Warner Losh <imp@bsdimp.com> wrote:
> > >
> > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <dim@freebsd.org> wrote:
> > > On 9 Oct 2021, at 13:37, Dimitry Andric <dim@FreeBSD.org> wrote:
> > > >
> > > > On 9 Oct 2021, at 09:46, FreeBSD User <freebsd@walstatt-de.de> wrote:
> > > >>
> > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e:
> > > >> Fri Oct  8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based
> > > >> appliance failed very early in the build process of the 13-STABLE
> > > >> sources as shown below. 13-STABLE is most recent, since the sources
> > are
> > > >> fetched every time the build process is triggered.
> > > > ...
> > > >>
> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > >> -s -o root -g wheel -m 555   compile_et
> > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > >>
> > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error:
> > undefined
> > > >> symbol: setupterm
> > > >>>>> referenced by Process.cpp
> > > >>>>>
> >  Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > >
> > > > It is complaining about ncurses functions; it seems that even though
> > the link step gets -lncursesw added, it still is not able to find the
> > symbol:
> > >
> > > Okay, this is because recently on -CURRENT, libtinfow got split off from
> > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > >
> > > This affects such cross-builds obviously, and manually adding -ltinfow
> > > to the link command line makes it link correctly.
> > >
> > > However, the 396851c20aebd commit is probably not suitable for MFC'ing
> > > to stable/13. Maybe we need to put some kind of kludge in
> > > share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1?
> > >
> > > Baptiste, any ideas? :)
> > >
> > > Add setupterm() to libegacy as a nop.
> >
> > That's not enough I think, it requires more ncurses functions than just
> > setupterm. And it actually calls them and checks the return values too,
> > IIRC. :)
> >
> 
> int setupterm(const char *t, int fd, int *errptr) { return OK; }
> int tigetnum(const char *t) { return 0; }
> TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> int del_curterm(TERMINAL *t) { return OK; }
> 
> should do the trick. I'll see just how crazy an idea this might be
> since we're trying to get the first stage tool to work on a -current
> host. the only thing that clang is really using is tigetnum to see
> if the terminal has color. Returning 0 tells it no.
> 
> Or we could contrive, during bootstrap, to ensure that
> LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs
> color error messages. They are nice to have, sure, but are not
> strictly needed if the alternative is monochrome error messages
> while building the system. There's already an ifdef protecting it:
> 
> /* Define if the setupterm() function is supported this platform. */
> #if defined(__FreeBSD__)
> /*
>  * This is only needed for terminalHasColors(). When disabled LLVM falls
> back
>  * to checking a list of TERM prefixes which is sufficient for a bootstrap
> tool.
>  */
> #define LLVM_ENABLE_TERMINFO 1
> #endif
> 
> It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD)
> or similar.

I do not quite understand how would it help.
You need to add this to HEAD sources back in time, not to the current
sources.