From nobody Sun Oct 10 04:45:22 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 ECD1812DC111 for ; Sun, 10 Oct 2021 04:45:23 +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 4HRq9b67lRz4ZWl for ; Sun, 10 Oct 2021 04:45:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id o15so10283434vsr.13 for ; Sat, 09 Oct 2021 21:45:23 -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=kzDblGeYE2vdA/2L1JfN2U0qa4a5+DL/JzHpVpY7fAs=; b=3fn3XedyouZ5udA86K1yptpF7wiAv1k5JTj2cG2L8ZdW+/+FyHg/JFT5yO5bw0WLXA ceEhyA9byy8ejktEdyupqBdXzhYaK0AyawGVRpZ8Zm2GP6IKNwfY7obbt/zreUZDHPgE GuIiVXjBajWIVS6pCeRS9AdFu7fHfCRnKKFygNg24NuaFdgKEfWkMBvTBiHTYd1WQyXa HInA+Ytxz2qZdYibNitrA0VndF8tw5fVR/L42PcElPm4+293OIUJaV36HtbPeTptqp5y jtQ4mOCPB44QbUwJKP/QVMsKm50P8EfHIoWfgCjr27aYC7jnrxuGiWkY+nqSqNvhCMjr vhnA== 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=kzDblGeYE2vdA/2L1JfN2U0qa4a5+DL/JzHpVpY7fAs=; b=5t3oVoe3uWxHvNCiIyfeTQ9rbYxZbJe4NGpcUv1vi2Pz1BiSpykhbsc1fHXZLRak1w 2+3MKHnAMU4UsGKutPWcWH5RalPTz4uYF5MOOSdnM4ik0xCLX5s97LPrqYZoMKdz502/ klFFqd4sr439JJhtnq0KlC10zHfJGd0KVZP4DbgBthRtY67VbS4E6zMuVLnn8KciOC2O tYQ/gf3bGPrbyPwF5VsWN7ilcCAMKdSzUQ/9ECjClVVReyyZqD7oOqKHrZC1naVRHOqU aMvh/qTAYAu8tdqQHglgrbkGH48GEtoWqAFA+FqGylEqZel/2LrlRiXzjG5m63Y63ChY iT4w== X-Gm-Message-State: AOAM532paWNjkk9Dq6D9gZv316XIkCMliIgrkvGmGvDBTEvK9DGUPL8Z kaoFAmEO+ycl2d/3yBjbspZOLAlUlJELo5AUMBrFrw== X-Google-Smtp-Source: ABdhPJzM5DJXVZLd6zrOECFk+i+7/QhSsUuwIOOh8mRKjoum+7q5Kw3dgev/ryhMu1SHyO0bp3Bd/sPS29KuT5Lr99Q= X-Received: by 2002:a05:6102:6ce:: with SMTP id m14mr18393194vsg.42.1633841123362; Sat, 09 Oct 2021 21:45:23 -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> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> In-Reply-To: <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> From: Warner Losh Date: Sat, 9 Oct 2021 22:45:22 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000c71db805cdf8478a" X-Rspamd-Queue-Id: 4HRq9b67lRz4ZWl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000c71db805cdf8478a Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin 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 > 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 < > 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). Warner --000000000000c71db805cdf8478a--