From nobody Sat Oct 09 22:47:35 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 8830D12D14E8 for ; Sat, 9 Oct 2021 22:47:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 4HRgF42yJ2z4vb7 for ; Sat, 9 Oct 2021 22:47:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id 17so1763050vkn.9 for ; Sat, 09 Oct 2021 15:47: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=n3MILKDNLzQy2GmDy9ODwgu7FhaHezLb194cyabOddw=; b=WR7TL4VElGboZOHPqweq5CSBH3MKDpaONlK5SdtruaAGOkY4OZfpVNGV0wY4p+guBi n3TdB8UTMdkz1GM+t5jFWE54MfnW2iEY/WxurHwaIz7Krh26Xz9Ui/v4XFkybZpW+Ma3 OYuuxw383+GPb2XFwGvzid2UcbE0uBh4AniddnbUxc9HJS2azv89IdNenp1Pn7gI1dfg Ti1FVxNAa+jIBukfsuewYiD5DqqZtRXeJnFC2f8haH89WWJAtz+k8k0/afBbAEbVW43h q2tyAaCq/JqEW7CXKPdCXkpQ4OLdl6KrsCiZxLFXfZILRgodGLsfSKM9OYGOdHkjdHas NK2A== 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=n3MILKDNLzQy2GmDy9ODwgu7FhaHezLb194cyabOddw=; b=bZNzI/Z5mbWHYFbtXrjp2NcSaMN5UWXBNgUlCQZla6vcfZniyO3lKWV49S3Zsu+Rr2 txC4DyRl7GleNU5oT4oIy/3mqu15EdIh5K2GiIrOUgRm4ZgKIXrdXb5qc9E9fqNvIJGL jj2uLd4+gPys5i2QTHQH0rSOAWteB6avm+AeoePW8eKR6JIBm1keY5YsA5tTk5JkgY7I tqFPHLkpheP+hQHsBUJ9gex6Ktes8kekq8g+XEpiLT4swhihiBjl788FJBdbc7xCA3ko m7blYRG9YVdA6JIsw5anuokipQoA0KatPcr+BUln/HtBmvVWLpFouVyMYAgV5vltbRLV mZ/A== X-Gm-Message-State: AOAM533ZYzt9xHWbJO2WBtNEUrCG70M9AVliedKXc+gNPKqoD/Fv7aUW 83DQzhbXAh0bTkUKlXK6jrIBu3mIDQuIMDLm5lIShSomyyGvdw== X-Google-Smtp-Source: ABdhPJzfKfJC4h46CN/ci6Z6QBk33nsbmKcQDhOXSpydccTiWG6CPwkSeai7B+BK7jgZyUAwg33HtvZAhXaNNkmBFXQ= X-Received: by 2002:ac5:c21a:: with SMTP id m26mr15706258vkk.18.1633819666412; Sat, 09 Oct 2021 15:47:46 -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: <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> From: Warner Losh Date: Sat, 9 Oct 2021 16:47:35 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Dimitry Andric Cc: FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Content-Type: multipart/alternative; boundary="000000000000d8095205cdf3484c" X-Rspamd-Queue-Id: 4HRgF42yJ2z4vb7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000d8095205cdf3484c Content-Type: text/plain; charset="UTF-8" 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. Warner --000000000000d8095205cdf3484c--