From nobody Sat Oct 9 23:29:39 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 2348E12D73C2 for ; Sat, 9 Oct 2021 23:29:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRh9X0Ck1z3Hg4 for ; Sat, 9 Oct 2021 23:29:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id p18so14598519vsu.7 for ; Sat, 09 Oct 2021 16:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rfk8kcaPYL5077oEz2oQZ5Gc2dDojovtsQo90wUTzgY=; b=Z0QnsG6fxoKqRu55y8FIDwX4OiK1FrobfZGAGDqa8AkI+0/YA+SumQvxcTf3/f0ZK4 GRhz309m35vytnnsqR+EiDjYC3JYm4aYIH354d0URyJ6gQz//IlVoSA2ZpINEJ1FVvZp VJvedlKTgI9ze1QXSyncOEM9JitWKwWA35YCQvkYxcSvzArIeFX60jHqMQ/PX0Oa+rCL h/0s7KtU+dlcFw+ADWyzclqcHPTiKKVo13ZNNF7XB9ALn5pnlnxKRwXPD0mP6UX5Bu2r vTdJSyAcs/y6IDFkajg57a3bHcqDIcNJ8c/Yyd3x7synwpIZGiUMqXWeKklca8cNcmzO 1+Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rfk8kcaPYL5077oEz2oQZ5Gc2dDojovtsQo90wUTzgY=; b=gBLs1cWLY1SXRx5u6y0465/Qq2ogeMf2KdiXBzSagLFaQPGrykeDQGRtqCjT61aRjG 6iIMzsVDF7SuAI9XIDMlfiuWwkS50U1v7OFO6G29iQjWr11tYqA7roQK7ZCaBtrDlPKO Rj91GY1o6QsO0wWhWf4wtmWTt/3Ajb2R3nNuCb9ig5qz/YxJJ5/GZ7MRJ+XHIyk0tCk6 6inSEyFGwQMLkRJCCpK01j/c1+eZHeN6kUJINgQ+vx0o3RivOrzrZwsPufXrlkaSlS5t kA/sAD0t2rmxix6WYk90lKxONFQ6/4VxxwQcnmcCRRg6cAR7VyF0kMjGRYqnihbemh/c /cNw== X-Gm-Message-State: AOAM532FQSyU9Z77poTxivw1JxhXNLygyZnty+U0pY1XjqU5xFeN52Wt ihyX3HXpddzYqBjLiaZncYWDWeKkGEFPwtCmu7rCGg== X-Google-Smtp-Source: ABdhPJzfpmfhdAyBVHGMAWET3v6gMI+XmEWzFhWW7Jlz71YBLe6h5VzI75dDJfyN49TZ21fHD1wT8sbEzp6kErz8hvw= X-Received: by 2002:a67:d28f:: with SMTP id z15mr18072155vsi.44.1633822191410; Sat, 09 Oct 2021 16:29:51 -0700 (PDT) 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 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Sat, 9 Oct 2021 17:29:39 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Konstantin Belousov Cc: Dimitry Andric , FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Content-Type: multipart/alternative; boundary="00000000000058795005cdf3df7f" X-Rspamd-Queue-Id: 4HRh9X0Ck1z3Hg4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000058795005cdf3df7f Content-Type: text/plain; charset="UTF-8" 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 > --00000000000058795005cdf3df7f--