Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
Date: Sun, 10 Oct 2021 14:43:06 UTC
On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin <bapt@freebsd.org> wrote:
>
> 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
>
I don't know if this is the right place to jump in, but I suspect this
is a related issue?
I'm trying to do the opposite - building 14 on a 13-STABLE machine. It
fails when trying to build ncurses:
root@p14s-bsd:/usr/src # uname -v
FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10
03:25:38 CEST 2021
root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
root@p14s-bsd:/usr/src # git pull
Already up to date.
root@p14s-bsd:/usr/src # git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
root@p14s-bsd:/usr/src # make buildworld > build.log
(...)
The full log is at http://eurostar.nebdal.no/build.log
It's all variations over this:
===> lib/ncurses/ncurses (obj,all,install)
Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o
/usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
implicit declaration of function '_nc_tiparm' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
TIPARM_1(set_a_background, bg),
^
/usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
macro 'TIPARM_1'
#define TIPARM_1(s,a) _nc_tiparm(1,s,a)
^
/usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
incompatible integer to pointer conversion passing 'int' to parameter
of type 'const char *' [-Werror,-Wint-conversion]
TIPARM_1(set_a_background, bg),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
macro 'TIPARM_1'
#define TIPARM_1(s,a) _nc_tiparm(1,s,a)
^~~~~~~~~~~~~~~~~
-DanielN