From nobody Sun Oct 10 05:15:54 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 39F0F17E0329 for ; Sun, 10 Oct 2021 05:16:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 4HRqs82yw7z4dLp for ; Sun, 10 Oct 2021 05:16:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2c.google.com with SMTP id a10so4746502vsr.1 for ; Sat, 09 Oct 2021 22:16:12 -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=ICUq3WMTWIgYWlh5SseVDQ+RelRwgmLv2uEbt6p/gWA=; b=dRMLDL75ekD0Dm+zFcsiUt7yevDWYZyihJzxaxOyKvmFSipbIk2VZ96a2tBVTEK6Sh SfOi3Z0VBP5W/eMsZ8p+BIWizCqavO0ZhlmxXOQ2J20wclYQmWfF6suX2DgOZjLphojt RATADHRtXAgHc1dmgaW9ebgvheNzz9wXBM9xxOXBvyx+lCDgJCjtKmz89E8AEW2W4TAp N3NgSkHpokFtJP5qiIGqj+gM6VHEawyBwCtK8ixOogl908JdBwUOEStQd2xqm/BrPzKz frtHQsts4SHk8BEvFc0Stdj0dVS6EyV8Cm3+eDfzA/pNA2ucD7w3pzVNGgqCiHef1pnp 0hbw== 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=ICUq3WMTWIgYWlh5SseVDQ+RelRwgmLv2uEbt6p/gWA=; b=Tm7Ed6aSYdu/fvQaIY+H3hDMcTiodOELNkKfQgSvQSsGoEXv8lBysA8JJCluy5ITN3 7Dv6Nxj+yq740qSMf2q1aq/mrGrfp6eSP8LumpkvcvHPOYiWoa596Ue4/Y65T7aeq+NO PEOLaDLSwHfR6QBbRrO+owb7ujQ4DlF4ulsKn4tbetLFBjNZjqHnQoS8Pi90z5uufHL8 SWKNATEFQsVSHliBiKgj1HnTIXgg/JnuP3Pi8b6B34JUMovhxJj4L/8iC/TDE/DOptuP 5mTc7ynwRN5dwAdVIeTq+XsNEjd8H9CqRjbXduF3fPzJTbHFxyGejfWnQUBxAKKUiHwP zSGA== X-Gm-Message-State: AOAM530s0qufzXAeWDKrdkGK+E6dgV2eTG8JBhu3njxJ6A7pkbBu7YvT i6JkoOAyKcqIRo+1DiRGQSTd6P0fVw5yEfmhUqXi3Q== X-Google-Smtp-Source: ABdhPJwEzkT7Qae+gddqDEQ7YTbHHJ0/vEIMwoGEfvX0uDKNpnXq7C3aSyxTf+dwkbHmleV+KvgnEOAW1SyNwdnKxVs= X-Received: by 2002:a67:fc8b:: with SMTP id x11mr3727496vsp.12.1633842965587; Sat, 09 Oct 2021 22:16:05 -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: From: Warner Losh Date: Sat, 9 Oct 2021 23:15:54 -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="000000000000953f2105cdf8b536" X-Rspamd-Queue-Id: 4HRqs82yw7z4dLp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=dRMLDL75; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2c:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org,walstatt-de.de] X-ThisMailContainsUnwantedMimeParts: Y --000000000000953f2105cdf8b536 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > 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 < >> dim@freebsd.org> 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). > Though it's still a 'patch the past' path forward... The fix is trivial to describe. Warner --000000000000953f2105cdf8b536--