Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
Date: Sun, 10 Oct 2021 20:17:40 UTC
10 oct. 2021 16:43:52 Daniel Nebdal <dnebdal@gmail.com>: > 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: >>>>> >>>>>> … >>>> dim@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