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

On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov <kostikbel@gmail.com>
> wrote:
> 
> > 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.
> >
> 
> Once merged, this would get stable building on current. But not older
> versions of stable, it is true. It's worth doing for that reason alone
> unless there's something clever we've not thought of yet with the current
> host.

We can put somewhere a patch and add instructions how to use it to patch
older HEADs and stable.  May be instructions and the reference to the patch
file should go into UPDATING 20211004 entry.