Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 09, 2021 at 09:46:24AM +0200, FreeBSD User 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. > > The framework for the build process is nanoBSD, the same error occurs > when building poudriere's jail based upon 13-STABLE from scratch via > the FreeBSD native build framework. > > "Cross building" of 13-STABLE on a CURRENT platform worked in most > cases and most time, hopefully this hickup is a solveable problem and > it would be nice to have this fixed. > > What is the reason for the linker fail? > > Are there any recommenadtions how to "cross build" 13-STABLE on a > 14-CURRENT platform in case the approach of mine s not a desireable on? > > Thanks in advance, > > Oliver > > [...] > > sh > /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)) > >>> in archive > >>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a > Anyone else still hitting this? I am. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 22:17, Baptiste Daroussin wrote: > > > > > 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 > > It is an entirely different storry that deserves its own investigation! > > I will try to find time in the next couple of days. > > In the meantile could you provide your make.conf, src.conf and src-env.conf? > > Best regards > Bapt Sure - they're plain enough: # cat /etc/make.conf cat: /etc/make.conf: No such file or directory # cat /etc/src.conf cat: /etc/src.conf: No such file or directory # cat /etc/src-env.conf WITH_META_MODE=YES I did try with meta mode disabled as well, with the same result. -DanielN
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
10 oct. 2021 16:43:52 Daniel Nebdal : > On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin 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 wrote: >>> On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > >> … d...@freebsd.org> >> … wrote: >> … > >> … the >> … since >> … /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh >> … c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et >> … ld: >> … Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >> … that >> … to >> … got >> … suitable >> … in >> … functions >> … return >> … OK; } >> … might >> … to >> … not >> … messages >> … protecting >> … disabled >> … for a >> … the >> … the >> … first >> … be to >> … probably we >> … having >> … but >> … > > 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 It is an entirely different storry that deserves its own investigation! I will try to find time in the next couple of days. In the meantile could you provide your make.conf, src.conf and src-env.conf? Best regards Bapt
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin 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 wrote:
> >
> > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
> > > >
> > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
> > > >
> > > > >
> > > > >
> > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > > > > 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 <
> > > > >> kostik...@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 <
> > > d...@freebsd.org>
> > > > >> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh
> > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > > >> d...@freebsd.org> wrote:
> > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> > > > >> > > > > > > > > > >
> > > > >> wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > > >> free...@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; }
> > > > >> > > > > >
> > > > >> > > > > >
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote:
>
> > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
> > >
> > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
> > >
> > > >
> > > >
> > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > > > 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 <
> > > >> kostik...@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 <
> > d...@freebsd.org>
> > > >> wrote:
> > > >> > > > > >
> > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh
> > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > >> d...@freebsd.org> wrote:
> > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > >
> > > >> wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > >> free...@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
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote:
> On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
> >
> > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
> >
> > >
> > >
> > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > > 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 <
> > >> kostik...@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 <
> d...@freebsd.org>
> > >> wrote:
> > >> > > > > >
> > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh
> wrote:
> > >> > > > > > > >
> > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > >> d...@freebsd.org> wrote:
> > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric >
> > >> wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > >> free...@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
>
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
>
> On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
>
> >
> >
> > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > 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 <
> >> kostik...@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
> >> wrote:
> >> > > > > >
> >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> >> > > > > > > >
> >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> >> d...@freebsd.org> wrote:
> >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> >> wrote:
> >> > > > > > > > >
> >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> >> free...@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
> >>
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
>
>
> On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> 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 <
>> kostik...@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
>> wrote:
>> > > > > >
>> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
>> > > > > > > >
>> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
>> d...@freebsd.org> wrote:
>> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
>> wrote:
>> > > > > > > > >
>> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
>> free...@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 &&
>>
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin 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 <
> kostik...@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
> wrote:
> > > > > >
> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > > > > > >
> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric
> wrote:
> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> wrote:
> > > > > > > > >
> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> free...@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
> > > > >
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 10:06 PM 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
> > > 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
> wrote:
> > > > >
> > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > > > > >
> > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric
> wrote:
> > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> wrote:
> > > > > > > >
> > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> free...@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
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
> > > 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
> > > > > wrote:
> > > > >
> > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > > > > >
> > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric
> > > > > > > wrote:
> > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > > > > > >
> > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User
> > > > 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
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
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
> > 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 wrote:
> > > >
> > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > > > >
> > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric
> > > > > > wrote:
> > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > > > > >
> > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User
> > > 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
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
> 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 wrote:
> > >
> > > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > > >
> > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote:
> > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > > > >
> > > > > > On 9 Oct 2021, at 09:46, FreeBSD User
> > 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.
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov
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 wrote:
> >
> > > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > > >
> > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote:
> > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > > >
> > > > > On 9 Oct 2021, at 09:46, FreeBSD User
> 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.
Warner
>
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote:
>
> > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > >
> > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote:
> > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > >
> > > > On 9 Oct 2021, at 09:46, FreeBSD User 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.
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote:
> On 9 Oct 2021, at 15:40, Warner Losh wrote:
> >
> > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote:
> > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > >
> > > On 9 Oct 2021, at 09:46, FreeBSD User 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.
Warner
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On 9 Oct 2021, at 15:40, Warner Losh wrote: > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > On 9 Oct 2021, at 09:46, FreeBSD User 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. :) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > On 9 Oct 2021, at 09:46, FreeBSD User 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. Warner -Dimitry > >
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > On 9 Oct 2021, at 09:46, FreeBSD User 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? :) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On 9 Oct 2021, at 09:46, FreeBSD User 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: c++ -O2 -pipe -fno-common -I/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/share/dim/src/freebsd/stable-13/lib/clang/include -I/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -I/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/legacy/usr/include -fno-exceptions -fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -static -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/legacy/usr/lib -o llvm-tblgen.full AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenHwModes.o CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAEmitter.o DFAPacketizerEmitter.o DirectiveEmitter.o DisassemblerEmitter.o ExegesisEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o GICombinerEmitter.o GlobalISel/CodeExpander.o GlobalISel/GIMatchDag.o GlobalISel/GIMatchDagEdge.o GlobalISel/GIMatchDagInstr.o GlobalISel/GIMatchDagOperands.o GlobalISel/GIMatchDagPredicate.o GlobalISel/GIMatchDagPredicateDependencyEdge.o GlobalISel/GIMatchTree.o GlobalISelEmitter.o InfoByHwMode.o InstrDocsEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptEmitter.o OptParserEmitter.o OptRSTEmitter.o PredicateExpander.o PseudoLoweringEmitter.o RISCVCompressInstEmitter.o RegisterBankEmitter.o RegisterInfoEmitter.o SDNodeProperties.o SearchableTableEmitter.o SubtargetEmitter.o SubtargetFeatureInfo.o TableGen.o Types.o WebAssemblyDisassemblerEmitter.o X86DisassemblerTables.o X86EVEX2VEXTablesEmitter.o X86FoldTablesEmitter.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/libexecinfo -lexecinfo -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/ncurses/ncurses -lncursesw -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/libthr -lpthread -legacy ld: error: undefined symbol: setupterm >>> referenced by Process.inc:336 >>> (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Unix/Process.inc:336) >>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >>> in archive >>> /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a ld: error: undefined symbol: tigetnum >>> referenced by Process.inc:354 >>> (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Unix/Process.inc:354) >>>
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 9, 2021 at 9:48 AM FreeBSD User 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. > > Same problem here with nanobsd too: Building a few weeks old FreeBSD CURRENT nanobsd image (like source from Sept 9) from a more recent dev environment (like CURRENT built Sept 25) is enough to reproduce this problem. Regards, Olivier
