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

On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote:
> > 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.
> 
> It fails to link because the bootstrap tools are built statically if they were
> linked dynamically that would solve the situation, because libncursesw.so is a
> linkscript which does the right thing.
>  
> Stupid question, why are bootstrap tools statically linked in the first place?
> If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine.
>   
> Imho we should remove the static linking here, the other way would be to
> provide a "flat" libncursesw.a for those cases on CURRENT. which I don't know how to
> provide without breaking things even more.
>    
> Best regards,
> Bapt

the reason being -DNO_SHARED is speeding up the bootstrap, so probably we need
to either investigate make ncurses a bootstrap lib for clang, or having kind of
an equivalent of what the linker script is doing for libncursesw.so but for
libncursesw.a.

Best regards,
Bapt