Date: Sat, 9 Oct 2021 22:41:30 -0600 From: Warner Losh <imp@bsdimp.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: 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: <CANCZdfoo_MZqPnZxEYRqCtOJp=mEhrjMbOkSkocD_UzsXx4ghw@mail.gmail.com> In-Reply-To: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> References: <20211009094624.3f3cacc8@jelly.fritz.box> <A047910E-DB49-45F8-9BF4-9233969AADAC@FreeBSD.org> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <CANCZdfrrXYMCdkdVEaUPr15nrO%2BLg=OG_bvoy8DCEr0QJVvaxA@mail.gmail.com> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000001d601e05cdf83ae8 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:06 PM Baptiste Daroussin <bapt@freebsd.org> 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. > I support this. It's a lot better than my idea. I did a deep dive with 'git blame' and after a look way back in time, this was added back when miniperl was added to the cross tools as a "while I'm here" change stop building the bootstrap shared and profile binaries (so it was an optimization). This will increase the build time a bit since we build libraries twice now (both static and shared). But we don't normally build libraries when bootstrapping, though. Back when this change was done, we built a lot during the bootstrapping. But that's no longer the case. 12 -> 13 (or current) will build a couple of libraries, so if they are built both shared and static the added time will be, at best, negligible. From older upgrades, more is built, but newer clang versions likely make it impossible to upgrade from such versions (likely time to GC them... I'll take a look at doing that). Warner P.S. Here's where it was added: commit ad879ce9552cb94f4709c6e41a31a060d1c9c335 Author: Marcel Moolenaar <marcel@FreeBSD.org> Date: Mon Nov 20 02:17:34 2000 +0000 Fix cross-building. o Move building libperl and miniperl from build-tools to cross-tools. libperl uses MACHINE_ARCH to determine the right configuration, which doesn't match the build machine when cross-building if they are built as build- tools. o Since miniperl needs to be built as a cross-tool, it needs to be installed under /usr/obj so that it can be used (cross-tools have a special object directory to avoid build conflicts. As a downside, you can't easily run cross-tools from their object directory). Remove the install and distribute override targets. To avoid having miniperl installed by installworld, remove it from SUBDIR. o We can't pickup miniperl from the object directory but since it's installed, depend on PATH. This is save, because the makefiles are run with a known path. o Build libperl again as part of the library target. A _libperl variable existed, but it was never defined. o Add chmod to the list of saved tools, because perl conditionally uses it during install. The bootstrap-tools and cross-tools targets are modified to avoid building profiled and shared libraries. While here, have these targets build static binaries instead of shared binaries. Approved by: markm Notes: svn path=/head/; revision=68927 > 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 > --0000000000001d601e05cdf83ae8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoo_MZqPnZxEYRqCtOJp=mEhrjMbOkSkocD_UzsXx4ghw>