Date: Sun, 10 Oct 2021 07:45:19 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Kyle Evans <kevans@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, Dimitry Andric <dim@freebsd.org>, FreeBSD User <freebsd@walstatt-de.de>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> In-Reply-To: <CANCZdfr5fAB6K4Zj82X35VX1ZVG4YL9POZRA7=qqqF3VeUHDMw@mail.gmail.com> References: <CANCZdfok58DEoCfZk_6w6p_3vJ9mV0FopAnuX6Av4C%2Bs8s5E8g@mail.gmail.com> <YWIifx%2BT0ETlzVIU@kib.kiev.ua> <CANCZdfpMHTKqRE=byupGpHpmJ-_bk9ZLTDv=_hxXYSkFMKa3Og@mail.gmail.com> <YWIrWtxlXwSpBi4i@kib.kiev.ua> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> <CANCZdfpu2tLJV%2B1RFwAbCeX-AvvUy7iKqKOP6fWcwwhjvYY=jA@mail.gmail.com> <CANCZdfrKCBHfem77PFxNzqO-Z9mB1QKgxYDXyK2GH488YLe4AA@mail.gmail.com> <CACNAnaGXDE1PRtHXTiX=AmG=M5kxtW%2B8J--iW_hgZa8R3=i7%2Bg@mail.gmail.com> <CANCZdfr5fAB6K4Zj82X35VX1ZVG4YL9POZRA7=qqqF3VeUHDMw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20211010054519.ennyyt3qba3reaop>