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

Reply: Daniel Nebdal : "Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm"
In reply to: Warner Losh : "Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Baptiste Daroussin <bapt_at_freebsd.org>
Date: Sun, 10 Oct 2021 05:45:19 UTC
On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans <kevans@freebsd.org> wrote:
> 
> > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh <imp@bsdimp.com> wrote:
> > >
> > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh <imp@bsdimp.com> wrote:
> > >
> > > >
> > > >
> > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin <bapt@freebsd.org>
> > > > wrote:
> > > >
> > > >> 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.
> > > >>
> > > >
> > > > We build so few libraries (usually none) that we can ditch this
> > > > optimization for
> > > > the upgrades (the libraries built are usually tiny).
> > > >
> > >
> > > Though it's still a 'patch the past' path forward... The fix is trivial
> > to
> > > describe.
> > >
> >
> > It doesn't sound like there's any need to 'patch the past'... the
> > status quo is that the static libncursesw is effectively "broken"
> > because consumers need to know to link to libtinfow. If the linker
> > script idea works (which it seems like it will) then it's a non-issue;
> > either we're building on a system that has the all-in-one libncursesw
> > or we're building against a linker script that also does the right
> > thing.
> >
> 
> Yea, the linker script notion is the only thing that's talked about so
> far that's something where we don't need to patch the past. The
> old tools know how to cope with the linker script and will bring the
> right things in. My comments were about removing -DNO_SHARED...
> 
> We should remove -DNO_SHARED as well from the bootstrap tools,
> but that's a separate issue if the linker script works.
> 
> Warner

This https://reviews.freebsd.org/D32435 should make freebsd stable 12 and 13
buildable out of box again on freebsd 14.

Best regards,
Bapt