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

Reply: Baptiste Daroussin : "Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm"
In reply to: Kyle Evans : "Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Warner Losh <imp_at_bsdimp.com>
Date: Sun, 10 Oct 2021 05:33:54 UTC
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