NetBSD Problem Report #57647

From www@netbsd.org  Sun Oct  8 15:05:08 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E40081A9238
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  8 Oct 2023 15:05:07 +0000 (UTC)
Message-Id: <20231008150506.469DF1A923A@mollari.NetBSD.org>
Date: Sun,  8 Oct 2023 15:05:06 +0000 (UTC)
From: davshao@gmail.com
Reply-To: davshao@gmail.com
To: gnats-bugs@NetBSD.org
Subject: lang/clang 6.0.6 update not usable for building other packages
X-Send-Pr-Version: www-1.0

>Number:         57647
>Category:       pkg
>Synopsis:       lang/clang 6.0.6 update not usable for building other packages
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 08 15:10:00 +0000 2023
>Closed-Date:    
>Last-Modified:  Thu Oct 19 03:45:01 +0000 2023
>Originator:     David Shao
>Release:        pkgsrc current
>Organization:
>Environment:
NetBSD xxxxxx.xxx 10.99.10 NetBSD 10.99.10 (GENERIC) #1: Sun Oct  8 04:32:15 PDT 2023  xxxxxx@xxxxxx.xxx:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
>Description:
For both modular and native pkgsrc on current NetBSD and on DragonFly, the update to clang 6.0.6 builds and installs, but seems to have no functionality building other packages.  For NetBSD for example:

===> Cleaning for wasi-compiler-rt-16.0.6
...
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for unwind.h
-- Looking for unwind.h - not found
-- Looking for rpc/xdr.h
-- Looking for rpc/xdr.h - not found
CMake Warning at cmake/Modules/CompilerRTUtils.cmake:281 (message):
  LLVM_CONFIG_PATH is deprecated, please use LLVM_CMAKE_DIR instead
Call Stack (most recent call first):
  CMakeLists.txt:92 (load_llvm_config)


CMake Warning at cmake/Modules/CompilerRTUtils.cmake:298 (message):
  LLVM source tree not found at
  "/usr/pkgsrc/lang/wasi-compiler-rt/work/llvm".  You are not using the
  monorepo layout.  This configuration is DEPRECATED.
Call Stack (most recent call first):
  CMakeLists.txt:92 (load_llvm_config)
-- Performing Test Terminfo_LINKABLE
-- Performing Test Terminfo_LINKABLE - Failed
-- Could NOT find Terminfo (missing: Terminfo_LINKABLE) 
-- Found ZLIB: /usr/pkg/lib/libz.so (found version "1.2.13")  
-- Found zstd: /usr/pkg/lib/libzstd.so  
-- Found LibXml2: /usr/pkg/lib/libxml2.so (found version "2.10.4") 
CMake Warning at cmake/Modules/CompilerRTUtils.cmake:326 (message):
  LLVMTestingSupport not found in LLVM_AVAILABLE_LIBS
Call Stack (most recent call first):
  CMakeLists.txt:92 (load_llvm_config)


-- LLVM_MAIN_SRC_DIR: "/usr/pkgsrc/lang/wasi-compiler-rt/work/llvm"
CMake Warning at cmake/Modules/CompilerRTUtils.cmake:338 (message):
  LLVM_MAIN_SRC_DIR (/usr/pkgsrc/lang/wasi-compiler-rt/work/llvm) does not
  exist.  You can override the inferred path by adding
  `-DLLVM_MAIN_SRC_DIR=<path_to_llvm_src>` to your CMake invocation where
  `<path_to_llvm_src>` is the path to the `llvm` directory in the
  `llvm-project` repo.  This will be treated as error in the future.
Call Stack (most recent call first):
  CMakeLists.txt:92 (load_llvm_config)


-- Found Python3: /usr/pkg/bin/python3.11 (found version "3.11.6") found components: Interpreter 
-- Performing Test CXX_SUPPORTS_UNWINDLIB_NONE_FLAG
-- Performing Test CXX_SUPPORTS_UNWINDLIB_NONE_FLAG - Failed
-- Looking for fopen in c
-- Looking for fopen in c - not found
-- Looking for __gcc_personality_v0 in gcc_s
-- Looking for __gcc_personality_v0 in gcc_s - not found
-- Performing Test C_SUPPORTS_NODEFAULTLIBS_FLAG
-- Performing Test C_SUPPORTS_NODEFAULTLIBS_FLAG - Failed
-- Performing Test COMPILER_RT_HAS_FFREESTANDING_FLAG
-- Performing Test COMPILER_RT_HAS_FFREESTANDING_FLAG - Failed
-- Performing Test COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG
-- Performing Test COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG - Failed

... (many other Failed)

CMake Error at cmake/Modules/CompilerRTUtils.cmake:144 (message):
  Cannot compile for wasm32:

  Change Dir:
  '/usr/pkgsrc/lang/wasi-compiler-rt/work/compiler-rt-16.0.6.src/cmake-pkgsrc-build/CMakeFiles/CMakeTmp'




  Run Build Command(s): /usr/pkg/bin/cmake -E env VERBOSE=1
  /usr/pkg/bin/gmake -f Makefile cmTC_4462f/fast

  make -f CMakeFiles/cmTC_4462f.dir/build.make
  CMakeFiles/cmTC_4462f.dir/build

  Building CXX object CMakeFiles/cmTC_4462f.dir/simple.cc.o

  /usr/pkgsrc/lang/wasi-compiler-rt/work/.cwrapper/bin/c++
  --sysroot=/usr/pkgsrc/lang/wasi-compiler-rt/work/.buildlink/wasi -O2
  -I/usr/pkg/include -I/usr/include -std=c++17
  --target=wasm32-unknown-unknown -MD -MT
  CMakeFiles/cmTC_4462f.dir/simple.cc.o -MF
  CMakeFiles/cmTC_4462f.dir/simple.cc.o.d -o
  CMakeFiles/cmTC_4462f.dir/simple.cc.o -c
  /usr/pkgsrc/lang/wasi-compiler-rt/work/compiler-rt-16.0.6.src/cmake-pkgsrc-build/CMakeFiles/simple.cc


  In file included from
  /usr/pkgsrc/lang/wasi-compiler-rt/work/compiler-rt-16.0.6.src/cmake-pkgsrc-build/CMakeFiles/simple.cc:2:


  In file included from
  /usr/pkgsrc/lang/wasi-compiler-rt/work/.buildlink/wasi/include/stdio.h:52:

  In file included from
  /usr/pkgsrc/lang/wasi-compiler-rt/work/.buildlink/wasi/include/__seek.h:4:


  /usr/pkgsrc/lang/wasi-compiler-rt/work/.buildlink/wasi/include/wasi/api.h:27:2:
  error: <wasi/api.h> is only supported on WASI platforms.

  #error <wasi/api.h> is only supported on WASI platforms.

   ^

  1 error generated.

>How-To-Repeat:
The above was for rebuilding using X11_TYPE=modular, but similar was observed for X11_TYPE=native on NetBSD.

/usr/pkgsrc/lang/wasi-compiler-rt
>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Wed, 11 Oct 2023 21:53:30 +0000
State-Changed-Why:
A fix was applied by ryoon@ earlier today, please update your tree and retry.

From: David Shao <davshao@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/57647: lang/clang 6.0.6 update not usable for building other packages
Date: Tue, 17 Oct 2023 19:13:35 -0700

 I am aware and have applied the fix for one package
 lang/wasi-compiler-rt. That enables
 that package to build.

 But let us think about the logic of this situation.  llvm and clang
 were updated from 15 to 16.
 How is the foundational cause the fault of that one package?

 Here is another demonstration.  For x11/xfce4-terminal, try switching
 the compiler to clang
 from NetBSD amd64 current, X11_TYPE native.

 PKGSRC_COMPILER=clang

 .include "../../lang/clang/buildlink3.mk"

 and whatever else in Makefile.  It seems to build fine.  Except if one
 looks at the config.log:

 Target: x86_64-unknown-netbsd10.99
 Thread model: posix
 InstalledDir: /usr/pkg/bin
 configure:4060: $? = 0
 configure:4049: gcc -v >&5
 clang version 16.0.6
 Target: x86_64-unknown-netbsd10.99
 Thread model: posix
 InstalledDir: /usr/pkg/bin
  "/usr/bin/ld" --eh-frame-hdr -pie -dynamic-linker /libexec/ld.elf_so
 -o a.out /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginS.o -zrelro
 -lc /usr/lib/crtendS.o /usr/lib/crtn.o
 /usr/bin/ld: /usr/lib/crt0.o: in function `___start':
 (.text+0x2d9): undefined reference to `main'
 clang-16: error: linker command failed with exit code 1 (use -v to see
 invocation)
 configure:4060: $? = 1
 configure:4049: gcc -V >&5
 clang-16: error: unsupported option '-V -Qunused-arguments'
 configure:4060: $? = 1
 configure:4049: gcc -qversion >&5
 clang-16: error: unknown argument '-qversion'; did you mean '--version'?
 configure:4060: $? = 1
 configure:4049: gcc -version >&5
 clang-16: error: unknown argument '-version'; did you mean '--version'?
 configure:4060: $? = 1
 configure:4080: checking whether the C compiler works
 configure:4102: gcc -O2 -I/usr/pkg/include -I/usr/pkg/include/glib-2.0
 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 -I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2
 -I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm
 -I/usr/pkg/include -I/usr/pkg/include/glib-2.0
 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 -I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2
 -I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm -Wl,-zrelro
 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib
 -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib conftest.c  >&5

 If I am reading this correctly, configure finds that clang 16 doesn't
 work and switches to NetBSD's current base gcc, which is
 good enough since it is gcc 10.

 I have doubts that clang-16 is functioning close to what it should do.

State-Changed-From-To: feedback->open
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Wed, 18 Oct 2023 16:08:32 +0000
State-Changed-Why:
Feedback received. Broader concern than just wasi-compiler-rt.

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/57647: lang/clang 6.0.6 update not usable for building
 other packages
Date: Wed, 18 Oct 2023 23:43:39 -0400

 On Tue, 17 Oct 2023 at 19:13:35 -0700, David Shao wrote:
 >I am aware and have applied the fix for one package
 >lang/wasi-compiler-rt. That enables
 >that package to build.
 >
 >But let us think about the logic of this situation.  llvm and clang
 >were updated from 15 to 16.
 >How is the foundational cause the fault of that one package?

 wasi-compiler-rt is a component directly associated with LLVM; it's
 part of the whole update to 16.0.6 that happened. So they are
 foundationally related.

 I had originally assumed the point of your PR was that you were trying
 to build one of the Firefox packages that depend on wasi-compiler-rt,
 and were blocked by this. (Firefox itself of course presently requires
 both GCC and clang to build.)

 >Here is another demonstration.  For x11/xfce4-terminal, try switching
 >the compiler to clang
 >from NetBSD amd64 current, X11_TYPE native.
 >
 >PKGSRC_COMPILER=3Dclang
 >
 >.include "../../lang/clang/buildlink3.mk"
 >
 >and whatever else in Makefile.  It seems to build fine.  Except if one
 >looks at the config.log:
 >
 >Target: x86_64-unknown-netbsd10.99
 >Thread model: posix
 >InstalledDir: /usr/pkg/bin
 >configure:4060: $? =3D 0
 >configure:4049: gcc -v >&5
 >clang version 16.0.6
 >Target: x86_64-unknown-netbsd10.99
 >Thread model: posix
 >InstalledDir: /usr/pkg/bin
 > "/usr/bin/ld" --eh-frame-hdr -pie -dynamic-linker /libexec/ld.elf_so
 >-o a.out /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginS.o -zrelro
 >-lc /usr/lib/crtendS.o /usr/lib/crtn.o
 >/usr/bin/ld: /usr/lib/crt0.o: in function `___start':
 >(.text+0x2d9): undefined reference to `main'
 >clang-16: error: linker command failed with exit code 1 (use -v to see
 >invocation)
 >configure:4060: $? =3D 1
 >configure:4049: gcc -V >&5
 >clang-16: error: unsupported option '-V -Qunused-arguments'
 >configure:4060: $? =3D 1
 >configure:4049: gcc -qversion >&5
 >clang-16: error: unknown argument '-qversion'; did you mean '--version'?
 >configure:4060: $? =3D 1
 >configure:4049: gcc -version >&5
 >clang-16: error: unknown argument '-version'; did you mean '--version'?
 >configure:4060: $? =3D 1
 >configure:4080: checking whether the C compiler works
 >configure:4102: gcc -O2 -I/usr/pkg/include -I/usr/pkg/include/glib-2.0
 >-I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 >-I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2
 >-I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm
 >-I/usr/pkg/include -I/usr/pkg/include/glib-2.0
 >-I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 >-I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2
 >-I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm -Wl,-zrelro
 >-L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib
 >-L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib conftest.c  >&5
 >
 >If I am reading this correctly, configure finds that clang 16 doesn't
 >work and switches to NetBSD's current base gcc, which is
 >good enough since it is gcc 10.
 >
 >I have doubts that clang-16 is functioning close to what it should do.

 Yes, though that is an entirely different issue. I just tested your
 example with clang-15, and it fails identically. Nothing to do with the
 recent update, it simply doesn't work here (at least, as invoked).
 Trying to use clang in general by default is probably not something
 that's been tested much, if at all, AFAIK.

 Regards,

 Dave

>Unformatted:

Home	PR Database Search