too long lines were shrinked: clang++ -I../include -I/usr/include/X11 -fPIC -pipe -march=native -fno-diagnostics-color -O2 -c ../classes/x11/x11src.cc -o obj/x11src.lo clang++ -I../include -I/usr/include/X11 -fPIC -pipe -march=native -fno-diagnostics-color -O2 -c ../classes/unix/xtermdis.cc -o obj/xtermdis.lo clang++ -I../include -I/usr/include/X11 -fPIC -pipe -march=native -fno-diagnostics-color -O2 -c ../classes/unix/xtermkey.cc -o obj/xtermkey.lo clang++ -I../include -I/usr/include/X11 -fPIC -pipe -march=native -fno-diagnostics-color -O2 -c ../classes/unix/xtermmouse.cc -o obj/xtermmouse.lo clang++ -I../include -I/usr/include/X11 -fPIC -pipe -march=native -fno-diagnostics-color -O2 -c ../classes/unix/xtermscr.cc -o obj/xtermscr.lo clang++ -L../../makes -L/var/tmp/portage/dev-libs/tvision-2.2.3/work/tvision/makes -L/usr/lib -L/usr/X11R6/lib -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -shared -Wl,-soname,librhtv.so.2.2.3 -fPIC -o librhtv.so.2.2.3 ../makes/obj/beep.lo ../makes/obj/drivevalid.lo . ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../lib64/crti.o is incompatible with elf32-i386 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/12/crtbeginS.o is incompatible with elf32-i386 ld.lld: error: ../makes/obj/beep.lo is incompatible with elf32-i386 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma-j4-20221215-050004 ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --jobserver-style=pipe" CC=clang CXX=clang++ gcc-config -l: [1] x86_64-pc-linux-gnu-12 * clang/llvm (if any): clang version 15.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/15 15.0.6 Python 3.10.9 Available Rust versions: [1] rust-bin-1.65.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 17.0.5_p8 [openjdk-bin-17] 2) Eclipse Temurin JDK 8.352_p08 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-17 system-vm The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): HEAD of ::gentoo commit e3c692f87cfa28ce78d0022da1825fd206476436 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Dec 16 03:02:12 2022 +0000 2022-12-16 03:02:12 UTC emerge -qpvO dev-libs/tvision [ebuild N ] dev-libs/tvision-2.2.3 USE="gpm nls -examples"
Created attachment 843021 [details] emerge-info.txt
Created attachment 843023 [details] dev-libs:tvision-2.2.3:20221216-032633.log
Created attachment 843025 [details] emerge-history.txt
Created attachment 843027 [details] environment
Created attachment 843029 [details] etc.clang.tar.bz2
Created attachment 843031 [details] etc.portage.tar.bz2
Created attachment 843033 [details] logs.tar.bz2
Created attachment 843035 [details] temp.tar.bz2
Created attachment 843037 [details] var.tmp.clang.tar.bz2
How should I interpret this? A 64-bit build is incompatible with 32-bit? Also the first two files listed are part of gcc, not of this package. Any hints in how to handle this? To me it looks like this is not about clang-16, but eventually the package isn't possible to build with clang at all.
That is very much possible. Is there an upstream bug report about issues with building clang? Are other distros, especially those who use clang as their main compiler, patching this somehow? Worst case we'll just have to block building it with clang. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/btop/btop-1.2.13-r1.ebuild#n27 here's a working example how to do it if worst comes to worst.
I'm not aware of a clang related upstream issue, but will check on this. There's not much activity upstream on this project and because the build system hasn't been modernized in years, I was actually thinking in dropping the package and placing the more modern implenentation from [1] into my overlay or ::guru. [1] https://github.com/magiblot/tvision
