From nobody Sat Oct 09 23:15:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 617FB12D52E2 for ; Sat, 9 Oct 2021 23:15:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRgrn6cTJz3GQ9; Sat, 9 Oct 2021 23:15:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 199NFBsL061562 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 10 Oct 2021 02:15:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 199NFBsL061562 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 199NFBL7061560; Sun, 10 Oct 2021 02:15:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Oct 2021 02:15:11 +0300 From: Konstantin Belousov To: Warner Losh Cc: Dimitry Andric , FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HRgrn6cTJz3GQ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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.