On Sat, Oct 9, 2021 at 10:45 PM Warner Losh <i...@bsdimp.com> wrote: > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin <b...@freebsd.org> > 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 < >> kostik...@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 <d...@freebsd.org> >> wrote: >> > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh <i...@bsdimp.com> wrote: >> > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < >> d...@freebsd.org> wrote: >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric <d...@freebsd.org> >> wrote: >> > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < >> free...@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
