CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/15 10:30:57 Modified files: devel/jdk : java.port.mk Log message: Enable building jdk/11 ports on sparc64. okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/15 10:30:00 Modified files: devel/jdk/11 : Makefile distinfo Added files: devel/jdk/11/patches: patch-src_hotspot_share_gc_shared_gc_globals_hpp Removed files: devel/jdk/11/patches: patch-src_hotspot_os_bsd_os_bsd_cpp Log message: Add sparc64 support. okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/13 13:11:32 Modified files: sysutils/u-boot/rk3588: Makefile distinfo Log message: Update to 2024-04. okay kettenis@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/02 09:42:52 Modified files: devel/jdk/1.8/patches: patch-hotspot_src_os_bsd_vm_os_bsd_cpp devel/jdk/11/patches: patch-src_hotspot_os_bsd_os_bsd_cpp devel/jdk/17/patches: patch-src_hotspot_os_bsd_os_bsd_cpp devel/jdk/21/patches: patch-src_hotspot_os_bsd_os_bsd_cpp Log message: Fix patch description to correctly describe the reason for the patch: Use the correct number of cpus when hw.smt=0 Pointed out by Kirill A. Korinsky and sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/02 07:33:48 Modified files: devel/jdk/21 : Makefile distinfo Added files: devel/jdk/21/patches: patch-src_hotspot_os_bsd_os_bsd_cpp Log message: Update to 21.0.3 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-04-16 * Take advantage of hyperthreading when hw.smt is enabled. Patch originally submitted by Kirill A. Korinsky
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/02 07:33:08 Modified files: devel/jdk/17 : Makefile distinfo Added files: devel/jdk/17/patches: patch-src_hotspot_os_bsd_os_bsd_cpp Log message: Update to 17.0.11 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-04-16 * Take advantage of hyperthreading when hw.smt is enabled. Patch originally submitted by Kirill A. Korinsky
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/01 14:55:10 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/11/patches: patch-make_common_NativeCompilation_gmk Added files: devel/jdk/11/patches: patch-src_hotspot_os_bsd_os_bsd_cpp Log message: Update to 11.0.23 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-04-16 * Take advantage of hyperthreading when hw.smt is enabled. Patch originally submitted by Kirill A. Korinsky
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/05/01 14:05:48 Modified files: devel/jdk/1.8 : Makefile distinfo Added files: devel/jdk/1.8/patches: patch-hotspot_src_os_bsd_vm_os_bsd_cpp patch-hotspot_src_os_cpu_bsd_sparc_vm_os_bsd_sparc_cpp Log message: Update to 8u412 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-04-16 * Fix implicit FPE exceptions on sparc64 * Take advantage of hyperthreading when hw.smt is enabled. Patch originally submitted by Kirill A. Korinsky .
Re: big-endian sysutils/u-boot/{rk356x,rk3588}
On Mar 21, 2024, at 1:16 PM, George Koehler wrote:
>
> I don't use u-boot, but I saw the powerpc bulk failing to package
> u-boot for rk356x and rk3588. This diff fixes the failures by adding
> 5 endian swaps. I don't know if my u-boot works, but I picked 2
> boards (1 from each package) and compared u-boot-rockchip.bin between
> powerpc and amd64: cmp -l|wc -l found 106 to 117 different bytes.
>
> Right now, powerpc is the only big-endian arch that can build this.
> mips64 and powerpc64 are missing devel/arm-none-eabi/gcc,aarch64; and
> sparc64 has BROKEN-sparc64 on u-boot. My 750 MHz PowerPC G4 takes
> over 3+1/2 hours to package rk3588 and over 7+1/2 hours for rk356x.
>
> May I get an ok from arm64 people?
> --gkoehler
George provided me the rock5b u-boot-rockchip.bin built on powerpc
to test. It boots fine and with no output differences.
I also built this on amd64 and tested the result on a rock5b. It
also boots fine and with no output differences.
okay kurt@
> Index: rk356x/Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/rk356x/Makefile,v
> diff -u -p -r1.4 Makefile
> --- rk356x/Makefile 17 Feb 2024 11:27:42 - 1.4
> +++ rk356x/Makefile 20 Mar 2024 22:34:34 -
> @@ -1,4 +1,5 @@
> VERSION= 2024.01
> +REVISION= 0
>
> SOC= rk356x
>
> Index: rk356x/files/rkbinpatch.c
> ===
> RCS file: /cvs/ports/sysutils/u-boot/rk356x/files/rkbinpatch.c,v
> diff -u -p -r1.1 rkbinpatch.c
> --- rk356x/files/rkbinpatch.c 17 Oct 2023 19:36:22 - 1.1
> +++ rk356x/files/rkbinpatch.c 20 Mar 2024 22:34:35 -
> @@ -16,6 +16,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -43,12 +44,13 @@ main(int argc, char *argv[])
>
> end = (char *)start + st.st_size;
> for (word = start; (void *)word < end; word++) {
> - if (*word == 0x12345678 && (void *)(word + 10) < end) {
> - data = *(word + 9);
> + if (le32toh(*word) == 0x12345678 &&
> +(void *)(word + 10) < end) {
> + data = le32toh(*(word + 9));
> if ((data & 0xff) == 150) {
> data &= 0xff00;
> data |= 115200;
> - *(word + 9) = data;
> + *(word + 9) = htole32(data);
> close(fd);
> return 0;
> }
> Index: rk356x/patches/patch-tools_rkcommon_c
> ===
> RCS file: rk356x/patches/patch-tools_rkcommon_c
> diff -N rk356x/patches/patch-tools_rkcommon_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ rk356x/patches/patch-tools_rkcommon_c 20 Mar 2024 22:34:35 -
> @@ -0,0 +1,23 @@
> +Add endian swaps for BE_ARCHS.
> +
> +Index: tools/rkcommon.c
> +--- tools/rkcommon.c.orig
> tools/rkcommon.c
> +@@ -454,7 +454,7 @@ int rkcommon_verify_header(unsigned char *buf, int siz
> + int ret;
> +
> + /* spl_hdr is abandon on header_v2 */
> +- if ((*(uint32_t *)buf) == RK_MAGIC_V2)
> ++ if (le32_to_cpu(*(uint32_t *)buf) == RK_MAGIC_V2)
> + return 0;
> +
> + ret = rkcommon_parse_header(buf, , _spl_info);
> +@@ -489,7 +489,7 @@ void rkcommon_print_header(const void *buf, struct ima
> + uint8_t image_type;
> + int ret, boot_size, init_size;
> +
> +- if ((*(uint32_t *)buf) == RK_MAGIC_V2) {
> ++ if (le32_to_cpu(*(uint32_t *)buf) == RK_MAGIC_V2) {
> + ret = rkcommon_parse_header_v2(buf, _v2);
> +
> + if (ret < 0) {
> Index: rk3588/Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/rk3588/Makefile,v
> diff -u -p -r1.3 Makefile
> --- rk3588/Makefile 6 Mar 2024 10:19:30 - 1.3
> +++ rk3588/Makefile 20 Mar 2024 22:34:35 -
> @@ -1,5 +1,5 @@
> VERSION= 2024.01-rc3
> -REVISION= 1
> +REVISION= 2
>
> SOC= rk3588
>
> Index: rk3588/files/rkbinpatch.c
> ===
> RCS file: /cvs/ports/sysutils/u-boot/rk3588/files/rkbinpatch.c,v
> diff -u -p -r1.1 rkbinpatch.c
> --- rk3588/files/rkbinpatch.c 26 Nov 2023 21:06:26 - 1.1
> +++ rk3588/files/rkbinpatch.c 20 Mar 2024 22:34:35 -
> @@ -43,12 +43,13 @@ main(int argc, char *argv[])
>
> end = (char *)start + st.st_size;
> for (word = start; (void *)word < end; word++) {
> - if (*word == 0x12345678 && (void *)(word + 14) < end) {
> - data = *(word + 13);
> + if (le32toh(*word) == 0x12345678 &&
> +(void *)(word + 14) < end) {
> + data = le32toh(*(word + 13));
> if ((data & 0xff) == 150) {
> data &= 0xff00;
> data |= 115200;
> - *(word + 13) = data;
> + *(word + 13) = htole32(data);
> close(fd);
> return 0;
> }
> Index: rk3588/patches/patch-tools_rkcommon_c
> ===
> RCS file: rk3588/patches/patch-tools_rkcommon_c
> diff -N rk3588/patches/patch-tools_rkcommon_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ rk3588/patches/patch-tools_rkcommon_c 20 Mar 2024 22:34:35 -
> @@ -0,0 +1,23 @@
> +Add endian swaps for BE_ARCHS.
> +
> +Index: tools/rkcommon.c
> +--- tools/rkcommon.c.orig
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/03/31 20:06:56 Modified files: devel/jdk/1.8 : Makefile distinfo devel/jdk/11 : Makefile distinfo devel/jdk/17 : Makefile distinfo devel/jdk/21 : Makefile distinfo Log message: New bootstrap jdks because pinsysctls was removed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/07 17:02:38 Modified files: devel/jdk/21 : Makefile distinfo Removed files: devel/jdk/21/patches: patch-make_modules_java_base_Lib_gmk patch-make_modules_java_desktop_lib_Awt2dLibraries_gmk Log message: Update to 21.0.2 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-01-16
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/07 17:01:59 Modified files: devel/jdk/17 : Makefile distinfo Removed files: devel/jdk/17/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-src_hotspot_os_cpu_bsd_aarch64_os_bsd_aarch64_cpp patch-src_hotspot_share_runtime_safefetch_static_hpp Log message: Update to 17.0.10 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-01-16
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/07 17:00:58 Modified files: devel/jdk/11 : Makefile distinfo Removed files: devel/jdk/11/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-make_lib_Awt2dLibraries_gmk patch-src_hotspot_share_code_nmethod_cpp patch-src_java_base_unix_native_libnet_DefaultProxySelector_c patch-src_java_desktop_unix_native_common_awt_awt_GraphicsEnv_h patch-src_java_desktop_unix_native_libawt_xawt_awt_gtk2_interface_c patch-src_java_desktop_unix_native_libawt_xawt_awt_gtk3_interface_c Log message: Update to 11.0.22 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-01-16
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/07 16:58:48 Modified files: devel/jdk/1.8 : Makefile distinfo Removed files: devel/jdk/1.8/patches: patch-common_autoconf_flags_m4 patch-common_autoconf_generated-configure_sh patch-common_autoconf_hotspot-spec_gmk_in patch-common_autoconf_jdk-options_m4 patch-hotspot_make_bsd_makefiles_aarch64_make patch-hotspot_make_bsd_makefiles_adlc_make patch-hotspot_make_bsd_makefiles_vm_make Log message: Update to 8u402 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2024-01-16
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/12/20 14:54:14 Modified files: devel/jdk/17 : Makefile Added files: devel/jdk/17/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk Log message: Reduce optimization on parse2.cpp due to multiple tests fail with assert(taken_cnt <= total_cnt) with fastdebug build on i386.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/12/11 07:39:45 Modified files: devel/jdk : Makefile Log message: Connect jdk-21 to the build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/12/11 07:38:55 Modified files: devel/jdk : java.port.mk Log message: Add support for jdk-21. okay ian@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/12/11 07:36:21 Log message: Import jdk-21. okay ian@ Status: Vendor Tag: kurt Release Tags: kurt_20231211 N ports/devel/jdk/21/Makefile N ports/devel/jdk/21/distinfo N ports/devel/jdk/21/patches/patch-make_common_NativeCompilation_gmk N ports/devel/jdk/21/patches/patch-make_modules_java_base_Lib_gmk N ports/devel/jdk/21/patches/patch-make_modules_java_desktop_lib_Awt2dLibraries_gmk N ports/devel/jdk/21/pkg/PFRAG.ci N ports/devel/jdk/21/pkg/DESCR N ports/devel/jdk/21/pkg/PLIST N ports/devel/jdk/21/pkg/README No conflicts created by this import
[NEW] devel/jdk/21
Attached is a port of jdk-21. I have already updated javaPathHelper
to support jdk-21. Below is the diff for java.port.mk to add
support for it as well.
okay for java.port.mk and to import devel/jdk/21?
Index: java.port.mk
===
RCS file: /cvs/ports/devel/jdk/java.port.mk,v
retrieving revision 1.42
diff -u -p -u -r1.42 java.port.mk
--- java.port.mk11 Mar 2022 18:50:14 - 1.42
+++ java.port.mk7 Dec 2023 18:28:15 -
@@ -1,4 +1,4 @@
-# Set MODJAVA_VER to 1.8, 11 or 17 based on the version of the jdk needed
+# Set MODJAVA_VER to 1.8, 11, 17 or 21 based on the version of the jdk needed
# for the port. Append a + (e.g., 11+) if any higher version is acceptable.
MODJAVA_VER?=
@@ -22,8 +22,9 @@ MODJAVA_VER?=
#
.if ${MODJAVA_VER:S/+//} != "1.8" && ${MODJAVA_VER:S/+//} != "11" && \
- ${MODJAVA_VER:S/+//} != "17"
-ERRORS+="Fatal: MODJAVA_VER must be one of 1.8, 11 or 17 with an optional
+ suffix."
+ ${MODJAVA_VER:S/+//} != "17" && ${MODJAVA_VER:S/+//} != "21"
+ERRORS+="Fatal: MODJAVA_VER must be one of 1.8, 11, 17 or 21"
+ERRORS+="with an optional + suffix."
.endif
.if ${MODJAVA_VER:S/+//} == "1.8"
@@ -38,9 +39,12 @@ MODJAVA_VER?=
.elif ${MODJAVA_VER:S/+//} == "11"
JAVA_HOME= ${LOCALBASE}/jdk-11
MODJAVA_BUILD_DEPENDS+= jdk->=11v0,<12v0:devel/jdk/11
-.else
+.elif ${MODJAVA_VER:S/+//} == "17"
JAVA_HOME= ${LOCALBASE}/jdk-17
MODJAVA_BUILD_DEPENDS+= jdk->=17v0,<18v0:devel/jdk/17
+.else
+JAVA_HOME= ${LOCALBASE}/jdk-21
+MODJAVA_BUILD_DEPENDS+= jdk->=21v0,<22v0:devel/jdk/21
.endif
.if ${MODJAVA_VER:M*+}
devel.jdk.21.tgz
Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/12/07 10:20:52 Modified files: java/javaPathHelper: Makefile distinfo Log message: Update to version 2.3 to add support for jdk-21
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/11/22 16:38:04 Modified files: devel/jdk/11 : Makefile Added files: devel/jdk/11/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-make_lib_Awt2dLibraries_gmk patch-src_hotspot_share_code_nmethod_cpp patch-src_java_base_unix_native_libnet_DefaultProxySelector_c patch-src_java_desktop_unix_native_common_awt_awt_GraphicsEnv_h patch-src_java_desktop_unix_native_libawt_xawt_awt_gtk2_interface_c patch-src_java_desktop_unix_native_libawt_xawt_awt_gtk3_interface_c Log message: Various clang-16 fixes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/11/20 11:31:14 Modified files: devel/jdk/1.8 : Makefile Added files: devel/jdk/1.8/patches: patch-common_autoconf_flags_m4 patch-common_autoconf_generated-configure_sh patch-common_autoconf_hotspot-spec_gmk_in patch-common_autoconf_jdk-options_m4 patch-hotspot_make_bsd_makefiles_aarch64_make patch-hotspot_make_bsd_makefiles_adlc_make patch-hotspot_make_bsd_makefiles_vm_make Log message: Fix clang 16 build: * Fix makefiles and autoconf to use CXXSTD_CXXFLAG correctly * Use -std=c++11 for clang builds. Note that gcc builds use gnu++98 but clang's gnu++98 is not fully compatible with gnu's - presumably what c++11 extensions are included varies. * Reduce optimization level for immediate_aarch64.cpp on aarch64 Also use âimagesâ for ALL_TARGET to skip building javadocs we are not installing.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/10/21 11:24:51 Modified files: devel/jdk/17 : Makefile distinfo devel/jdk/17/patches: patch-make_common_NativeCompilation_gmk Added files: devel/jdk/17/patches: patch-src_hotspot_os_cpu_bsd_aarch64_os_bsd_aarch64_cpp patch-src_hotspot_share_runtime_safefetch_static_hpp Removed files: devel/jdk/17/patches: patch-make_autoconf_flags-ldflags_m4 patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp patch-src_hotspot_os_bsd_os_bsd_cpp patch-src_hotspot_share_runtime_os_hpp patch-src_hotspot_share_runtime_stackOverflow_cpp patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_c patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_h Log message: Update to 17.0.9 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2023-10-17
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/10/21 07:58:55 Modified files: devel/jdk/11 : Makefile distinfo Removed files: devel/jdk/11/patches: patch-make_autoconf_flags-ldflags_m4 patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp patch-src_hotspot_os_bsd_os_bsd_cpp patch-src_hotspot_share_runtime_os_hpp patch-src_hotspot_share_runtime_thread_cpp patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_c patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_h Log message: Update to 11.0.21 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2023-10-17
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/10/20 20:25:02 Modified files: devel/jdk/1.8 : Makefile distinfo Removed files: devel/jdk/1.8/patches: patch-common_autoconf_generated-configure_sh patch-common_autoconf_toolchain_m4 patch-hotspot_src_cpu_aarch64_vm_templateInterpreter_aarch64_cpp patch-hotspot_src_os_bsd_vm_os_bsd_cpp patch-hotspot_src_os_cpu_bsd_sparc_vm_os_bsd_sparc_cpp patch-hotspot_src_share_vm_runtime_os_hpp patch-hotspot_src_share_vm_runtime_thread_cpp Log message: Update to 8u392 GA: * Contains upstream bug and security fixes: https://openjdk.org/groups/vulnerability/advisories/2023-10-17
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/14 08:31:09 Modified files: devel/jdk/1.8 : Makefile devel/jdk/1.8/patches: patch-common_autoconf_generated-configure_sh patch-hotspot_src_os_cpu_bsd_sparc_vm_os_bsd_sparc_cpp Log message: Support setting thread stack sizes on sparc64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/09 11:59:35 Modified files: devel/jdk/11 : Makefile Removed files: devel/jdk/11/files: cacerts Log message: Use the distributed cacerts Enable the Shenandoah GC
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/09 11:58:28 Modified files: devel/jdk/17 : Makefile Removed files: devel/jdk/17/files: cacerts Log message: Use the distributed cacerts
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/09 11:57:24 Modified files: devel/jdk/1.8 : Makefile Removed files: devel/jdk/1.8/files: cacerts Log message: Use the distributed cacerts.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/01 19:12:13 Modified files: devel/jdk/17 : Makefile distinfo Log message: Update to 17.0.8 GA: * Contains upstream bug and security fixes: https://foojay.io/java-17/?version=17.0.8=072023=component https://openjdk.org/groups/vulnerability/advisories/2023-07-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/01 13:07:04 Modified files: devel/jdk/11 : Makefile distinfo Log message: Update to 11.0.20 GA: * Contains upstream bug and security fixes: https://foojay.io/java-11/?version=11.0.20=072023=component https://openjdk.org/groups/vulnerability/advisories/2023-07-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/01 09:32:16 Modified files: devel/jdk/1.8 : Makefile distinfo Log message: Update to 8u382 GA: * Contains upstream bug and security fixes: https://foojay.io/java-8/?version=openjdk8u382=072023=component https://openjdk.org/groups/vulnerability/advisories/2023-07-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/07/31 21:27:15 Modified files: devel/jdk/11 : Makefile Log message: Prevent configure from picking up pandoc as well.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/07/31 21:14:08 Modified files: devel/jdk/17 : Makefile Log message: Pass CONFIGURE_ARGS to ensure we don't pickup unwanted build depends. Fixes junking in bulk builds.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/07/27 19:53:00 Modified files: devel/jdk/1.8 : Makefile Log message: Pass CONFIGURE_ARGS/ENV to ensure we don't pickup unwanted build depends. Fixes junking in bulk builds.
Re: jdk fails to build (gmkdir)
On Jul 27, 2023, at 5:44 AM, Antoine Jacoutot wrote: > > Hi. > > It seems gmkdir is picked up if present at configure time. > If junked then the build fails with: Thanks. Fix committed. I’ll look over 1.8 and 17 for similar corrections as well.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/07/27 11:09:42 Modified files: devel/jdk/11 : Makefile Log message: Pass CONFIGURE_ARGS to ensure we don't pickup unwanted build depends. Fixes junking in bulk builds reported by ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/07/02 04:26:09 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/17 : Makefile distinfo Log message: Update bootstraps with nobtcfi in prep for BTI okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/06/30 09:49:51 Modified files: devel/jdk/1.8 : Makefile distinfo Added files: devel/jdk/1.8/patches: patch-hotspot_src_os_cpu_bsd_sparc_vm_os_bsd_sparc_cpp patch-hotspot_src_share_vm_runtime_globals_hpp Log message: * Update bootstraps with nobtcfi in prep for BTI * Sync sparc64 signal handling code with linux updates * Work-around a stablilty issue on sparc64 okay sthen@
Re: JDKs and control-flow enforcement
On Jun 27, 2023, at 10:48 AM, Stuart Henderson wrote:
>
> On 2023/06/27 08:18, Kurt Miller wrote:
>> The CLA situation is no more. Greg and I have given up on getting
>> BSD support merged upstream. It became clear that Oracle would not
>> accept our code without a deep pocket corporation backing the
>> effort.
>>
>> If you have tested diffs already baked, please go ahead and commit
>> them. I can build new bootstraps after it lands.
>
> Not super-tidy, but this does the trick. I don't see how to tell
> for sure whether a binary is built with this or not (it's possible
> that it's "LOOS+5a3dbe8" in readelf -l) so I haven't made any
> extra checks like are done for wxneeded.
>
> Will commit it to move ahead, happy to test any tweaks if wanted.
This is fine for now. Okay kurt@
> Index: 1.8/Makefile
> ===
> RCS file: /cvs/ports/devel/jdk/1.8/Makefile,v
> retrieving revision 1.81
> diff -u -p -r1.81 Makefile
> --- 1.8/Makefile 19 May 2023 01:43:08 - 1.81
> +++ 1.8/Makefile 27 Jun 2023 14:11:22 -
> @@ -1,5 +1,6 @@
> ONLY_FOR_ARCHS= i386 amd64 aarch64 sparc64
> USE_WXNEEDED= Yes
> +USE_NOBTCFI= Yes
> DPB_PROPERTIES= parallel
>
> COMMENT= OpenJDK Software Development Kit v${V}
> @@ -11,7 +12,7 @@ V= ${BASE_VER}.${UPDATE_VER}.${BUILD_VE
> PKGNAME= jdk-${V}
> PKGSTEM= jdk-${BASE_VER}
> EPOCH= 0
> -REVISION= 0
> +REVISION= 1
>
> DIST_SUBDIR= jdk
> DISTNAME= jdk8u${UPDATE_VER}-${BUILD_VER}.${BSD_PORT_REL}
> Index: 1.8/patches/patch-common_autoconf_generated-configure_sh
> ===
> RCS file: 1.8/patches/patch-common_autoconf_generated-configure_sh
> diff -N 1.8/patches/patch-common_autoconf_generated-configure_sh
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ 1.8/patches/patch-common_autoconf_generated-configure_sh 27 Jun 2023
> 14:11:22 -
> @@ -0,0 +1,21 @@
> +Index: common/autoconf/generated-configure.sh
> +--- common/autoconf/generated-configure.sh.orig
> common/autoconf/generated-configure.sh
> +@@ -41202,7 +41202,7 @@ fi
> + { $as_echo "$as_me:${as_lineno-$LINENO}: checking if ld requires -z
> wxneeded" >&5
> + $as_echo_n "checking if ld requires -z wxneeded... " >&6; }
> + PUSHED_LDFLAGS="$LDFLAGS"
> +-LDFLAGS="$LDFLAGS -Wl,-z,wxneeded"
> ++LDFLAGS="$LDFLAGS -Wl,-z,wxneeded -Wl,-z,nobtcfi"
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> + /* end confdefs.h. */
> + int main() { }
> +@@ -41212,7 +41212,7 @@ if ac_fn_cxx_try_link "$LINENO"; then :
> + if $READELF -l conftest$ac_exeext | $GREP OPENBSD_WXNEED >
> /dev/null; then
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> + $as_echo "yes" >&6; }
> +-LDFLAGS_JDK="${LDFLAGS_JDK} -Wl,-z,wxneeded"
> ++LDFLAGS_JDK="${LDFLAGS_JDK} -Wl,-z,wxneeded -Wl,-z,nobtcfi"
> + else
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> + $as_echo "yes" >&6; }
> Index: 1.8/patches/patch-common_autoconf_toolchain_m4
> ===
> RCS file: 1.8/patches/patch-common_autoconf_toolchain_m4
> diff -N 1.8/patches/patch-common_autoconf_toolchain_m4
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ 1.8/patches/patch-common_autoconf_toolchain_m4 27 Jun 2023 14:11:22 -
> @@ -0,0 +1,18 @@
> +Index: common/autoconf/toolchain.m4
> +--- common/autoconf/toolchain.m4.orig
> common/autoconf/toolchain.m4
> +@@ -855,12 +855,12 @@ AC_DEFUN_ONCE([TOOLCHAIN_MISC_CHECKS],
> + if test "`uname -s`" = "OpenBSD"; then
> + AC_MSG_CHECKING([if ld requires -z wxneeded])
> + PUSHED_LDFLAGS="$LDFLAGS"
> +-LDFLAGS="$LDFLAGS -Wl,-z,wxneeded"
> ++LDFLAGS="$LDFLAGS -Wl,-z,wxneeded -Wl,-z,nobtcfi"
> + AC_LINK_IFELSE([AC_LANG_SOURCE([[int main() { }]])],
> + [
> + if $READELF -l conftest$ac_exeext | $GREP OPENBSD_WXNEED >
> /dev/null; then
> + AC_MSG_RESULT([yes])
> +-LDFLAGS_JDK="${LDFLAGS_JDK} -Wl,-z,wxneeded"
> ++LDFLAGS_JDK="${LDFLAGS_JDK} -Wl,-z,wxneeded -Wl,-z,nobtcfi"
> + else
> + AC_MSG_RESULT([yes])
> + fi
> Index: 11/Makefile
> ===
> RCS file: /cvs/ports/devel/jdk/11/Makefile,v
> retrieving revi
Re: JDKs and control-flow enforcement
On Jun 27, 2023, at 5:41 AM, Stuart Henderson wrote: > > On amd64 with a processor with IBT support running a kernel with the > control-flow enforcement diff that's being tried in snapshots, the > various Java-compiled binaries fail. > > Some information pasted below and hs log attached; I didn't bother with > the gdb backtrace as it just shows the signal handler in the lead-up to > VMError::report_and_die). > > There's a good chance aarch64 will have the same on CPUs which do > control-flow integrity too (I think that may just be M2, not sure). > > Bearing in mind the CLA situation I won't send a diff but adding > -Wl,-z,nobtcfi in the same place that -Wl,-z,wxneeded is added does > the trick to fix things (and while I think it won't matter for the > package it would be helpful to add USE_NOBTCFI=Yes to the port so > we can find it more easily). > > We'll need new bootstraps at some point (for people building jdk > themselves on newer machines) but that can be done later than > fixing the package binaries (I can help with bootstrap builds if > wanted). > Thanks for the in-depth explanation. The CLA situation is no more. Greg and I have given up on getting BSD support merged upstream. It became clear that Oracle would not accept our code without a deep pocket corporation backing the effort. If you have tested diffs already baked, please go ahead and commit them. I can build new bootstraps after it lands. > > $ dmesg | grep -B1 ,IBT | head -2 > cpu0: 12th Gen Intel(R) Core(TM) i5-1245U, 1575.89 MHz, 06-9a-04 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > > $ /usr/local/jdk-11/bin/java # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x05fe614cdc20, pid=55171, tid=6586713654336 > # > # JRE version: (11.0.19+7) (build ) > # Java VM: OpenJDK 64-Bit Server VM (11.0.19+7-1, mixed mode, tiered, > compressed oops, g1 gc, bsd-amd64) > # Problematic frame: > # j java.lang.Object.()V+-289299944 java.base > # > # Core dump will be written. Default location: /home/sthen/java.core > # > # An error report file with more information is saved as: > # /home/sthen/hs_err_pid55171.log > Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled > # > # > Abort trap (core dumped) >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/06/17 15:15:29 Modified files: devel/jdk/11 : Makefile devel/jdk/17 : Makefile Added files: devel/jdk/11/patches: patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_c patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_h devel/jdk/17/patches: patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_c patch-src_java_base_unix_native_libjava_ProcessHandleImpl_unix_h Log message: Start using waitid(2)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/18 19:43:09 Modified files: devel/jdk/1.8 : Makefile devel/jdk/1.8/patches: patch-hotspot_src_os_bsd_vm_os_bsd_cpp Added files: devel/jdk/1.8/patches: patch-hotspot_src_share_vm_runtime_os_hpp patch-hotspot_src_share_vm_runtime_thread_cpp Log message: Disable stack guard pages in the primordial thread only to fix java integration with programs like libreoffice. The primordial thread's stack permissions are immutable so stack guard pages can not be placed on it. Fortunately the launcher for normal java programs uses a separate thread to start the JVM and stack guard pages may be placed on thread stacks. Libreoffice, on the other hand, launches the JVM in the primordial thread and stack guard pages fail to be placed. Disabling stack guard pages for the primordial thread allows libreoffice to use java again, but with the side effect of breaking StackOverflowError exceptions on the primordial thread only.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/18 19:41:33 Modified files: devel/jdk/17 : Makefile Added files: devel/jdk/17/patches: patch-src_hotspot_os_bsd_os_bsd_cpp patch-src_hotspot_share_runtime_os_hpp patch-src_hotspot_share_runtime_stackOverflow_cpp Log message: Disable stack guard pages in the primordial thread only to fix java integration with libreoffice. The primordial thread's stack permissions are immutable so stack guard pages can not be placed on it. Fortunately the launcher for normal java programs uses a separate thread to start the JVM and stack guard pages may be placed on thread stacks. Libreoffice, on the other hand, launches the JVM in the primordial thread and stack guard pages fail to be placed. Disabling stack guard pages for the primordial thread allows libreoffice to use java again, but with the side effect of breaking StackOverflowError exceptions on the primordial thread only.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/17 11:06:10 Modified files: devel/jdk/11 : Makefile devel/jdk/11/patches: patch-make_common_NativeCompilation_gmk Added files: devel/jdk/11/patches: patch-src_hotspot_os_bsd_os_bsd_cpp patch-src_hotspot_share_runtime_os_hpp patch-src_hotspot_share_runtime_thread_cpp Log message: Disable stack guard pages in the primordial thread only to fix java integration with libreoffice. The primordial thread's stack permissions are immutable so stack guard pages can not be placed on it. Fortunately the launcher for normal java programs uses a separate thread to start the JVM and stack guard pages may be placed on thread stacks. Libreoffice, on the other hand, launches the JVM in the primordial thread and stack guard pages fail to be placed. Disabling stack guard pages for the primordial thread allows libreoffice to use java again, but with the side effect of breaking StackOverflowError exceptions on the primordial thread only. Reviewed by semarie@ & robert@. Okay robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/12 06:43:56 Modified files: devel/jdk/17 : Makefile distinfo Log message: Update to 17.0.7 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?version=17.0.7=042023=component https://openjdk.org/groups/vulnerability/advisories/2023-04-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/12 06:41:37 Modified files: devel/jdk/11 : Makefile distinfo Log message: Update to 11.0.19 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?version=11.0.19=042023=component https://openjdk.org/groups/vulnerability/advisories/2023-04-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/05/12 06:37:17 Modified files: devel/jdk/1.8 : Makefile distinfo Log message: Update to 8u372 GA: * Contains upstream bug and security fixes: https://foojay.io/java-8/?version=openjdk8u372=042023=component https://openjdk.org/groups/vulnerability/advisories/2023-04-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/23 07:59:29 Modified files: devel/jdk/1.8 : Makefile Added files: devel/jdk/1.8/patches: patch-hotspot_src_os_bsd_vm_os_bsd_cpp Log message: Remove syscall(2) use.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/15 09:55:39 Modified files: devel/jdk/11 : Makefile Log message: Be sure to use system awk and not pickup a silent depend on gawk. Fixes build failures when gawk was junked as noted by tb@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/03 13:32:57 Modified files: devel/jdk/1.8 : Makefile devel/jdk/11 : Makefile devel/jdk/11/patches: patch-make_common_NativeCompilation_gmk devel/jdk/17 : Makefile devel/jdk/17/patches: patch-make_common_NativeCompilation_gmk Added files: devel/jdk/1.8/patches: patch-hotspot_src_cpu_aarch64_vm_templateInterpreter_aarch64_cpp devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp devel/jdk/17/patches: patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp Log message: * Remove errant aarch64 hotspot assembly instruction that was reading from libjvm.so .text segment. This is clearly not was intended here. Found by exec only. * Remove USE_NOEXECONLY flags. * Disable -Werror for 11 & 17 to so clang 15 can build them.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/01/31 12:50:04 Modified files: devel/jdk/17 : Makefile distinfo devel/jdk/17/pkg: PLIST Log message: Update to 17.0.6 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?version=17.0.6=012023=component https://openjdk.org/groups/vulnerability/advisories/2023-01-17 * Update bootstraps and remove libc copy okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/01/31 12:48:02 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/11/pkg: PLIST Log message: Update to 11.0.18 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?version=11.0.18=012023=component https://openjdk.org/groups/vulnerability/advisories/2023-01-17 * Update bootstraps and remove libc copy okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/01/31 12:43:09 Modified files: devel/jdk/1.8 : Makefile distinfo Log message: Update to 8u362 GA: * Contains upstream bug and security fixes: https://foojay.io/java-8/?tab=component=openjdk8u362=012023 https://openjdk.org/groups/vulnerability/advisories/2023-01-17 * Update bootstraps and remove libc copy okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/11/10 10:23:32 Modified files: devel/jdk/17 : Makefile distinfo devel/jdk/17/pkg: PLIST Log message: Update to 17.0.5 GA: * Contains upstream bug and security fixes: https://foojay.io/java-17/?version=17.0.5=102022=component https://openjdk.org/groups/vulnerability/advisories/2022-10-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/11/10 10:22:09 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/11/pkg: PLIST Log message: Update to 11.0.17 GA: * Contains upstream bug and security fixes: https://foojay.io/java-11/?version=11.0.17=102022=component https://openjdk.org/groups/vulnerability/advisories/2022-10-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/11/10 10:19:26 Modified files: devel/jdk/1.8 : Makefile distinfo Log message: Update to 8u352 GA: * Contains upstream bug and security fixes: https://foojay.io/java-8/?tab=highlights=openjdk8u352=102022 https://openjdk.org/groups/vulnerability/advisories/2022-10-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/08/07 15:55:37 Modified files: devel/jdk/17 : Makefile distinfo Log message: Update to 17.0.4 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?quarter=072022=allissues https://openjdk.org/groups/vulnerability/advisories/2022-07-19 * Update bootstraps okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/08/07 15:53:29 Modified files: devel/jdk/11 : Makefile distinfo Log message: Update to 11.0.16 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?quarter=072022=allissues https://openjdk.org/groups/vulnerability/advisories/2022-07-19 * Update bootstraps okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/08/07 15:49:38 Modified files: devel/jdk/1.8 : Makefile distinfo Removed files: devel/jdk/1.8/patches: patch-hotspot_src_cpu_aarch64_vm_pauth_aarch64_hpp patch-hotspot_src_os_cpu_bsd_aarch64_vm_pauth_bsd_aarch64_inline_hpp patch-make_common_MakeBase_gmk Log message: Update to 8u342 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-8/?tab=allissues=openjdk8u342 https://openjdk.org/groups/vulnerability/advisories/2022-07-19 * Update bootstraps and strip debuginfo from them to keep them as small as possible okay sthen@
Re: benchmarks/fio: hidden dependency on libnfs
On Jul 29, 2022, at 10:12 AM, Theo Buehler wrote:
>
> As reported by mpi on ICB, fio has a hidden dep on libnfs. We could also
> neuter this by adding --disable-nfs to CONFIGURE_ARGS.
>
Let’s include it. Thanks for fix it. Okay kurt@
> Index: Makefile
> ===
> RCS file: /cvs/ports/benchmarks/fio/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile 20 May 2022 14:12:21 - 1.8
> +++ Makefile 29 Jul 2022 14:03:49 -
> @@ -4,6 +4,7 @@ GH_ACCOUNT= axboe
> GH_PROJECT= fio
> GH_TAGNAME= fio-3.30
> PKGNAME= ${GH_TAGNAME}
> +REVISION=0
>
> CATEGORIES= benchmarks
>
> @@ -19,7 +20,7 @@ PERMIT_PACKAGE= Yes
> COMPILER= base-clang ports-gcc
> COMPILER_LANGS= c
>
> -WANTLIB= c m pthread z
> +WANTLIB= c m pthread nfs z
>
> USE_GMAKE=Yes
> SEPARATE_BUILD= Yes
> @@ -31,5 +32,7 @@ MAKE_FLAGS= V=1 \
>
> CONFIGURE_ARGS= --disable-optimizations \
> --disable-native
> +
> +LIB_DEPENDS= devel/libnfs
>
> .include
>
Re: sparc64 bulk build report
On Jul 25, 2022, at 12:40 AM, k...@openbsd.org wrote: > Build failures: 38 > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/jdk/1.8.log I’ve noticed an intermittent jdk crash on my sparc64 build machine too. I’ve investigated it at length but have not determined the cause yet. Please let me know if if this build failure is persistent. Thanks, -Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/05/20 08:12:21 Modified files: benchmarks/fio : Makefile distinfo Log message: Update to fio-3.30
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/05/14 11:23:43 Modified files: devel/jdk/17 : Makefile distinfo Log message: Update to 17.0.3 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?quarter=042022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/05/14 11:21:32 Modified files: devel/jdk/11 : Makefile distinfo Removed files: devel/jdk/11/patches: patch-src_java_net_http_share_classes_jdk_internal_net_http_Stream_java Log message: Update to 11.0.15 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?quarter=042022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/05/14 11:16:41 Modified files: devel/jdk/1.8 : Makefile distinfo Added files: devel/jdk/1.8/patches: patch-hotspot_src_cpu_aarch64_vm_pauth_aarch64_hpp patch-hotspot_src_os_cpu_bsd_aarch64_vm_pauth_bsd_aarch64_inline_hpp patch-make_common_MakeBase_gmk Log message: Update to 8u332 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-8/?quarter=042022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/02/20 06:51:03 Modified files: devel/jdk/11 : Makefile devel/jdk/11/patches: patch-src_java_base_share_classes_java_net_AbstractPlainDatagramSocketImpl_java Added files: devel/jdk/11/patches: patch-src_java_net_http_share_classes_jdk_internal_net_http_Stream_java Log message: Backport 10.0.14.1 bugfix: 8218546: Unable to connect to https://google.com using java.net.HttpClient
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/02/19 12:18:59 Modified files: devel/jdk/1.8 : Makefile distinfo Removed files: devel/jdk/1.8/patches: patch-hotspot_make_bsd_makefiles_gcc_make patch-hotspot_src_cpu_aarch64_vm_register_aarch64_hpp patch-hotspot_src_cpu_x86_vm_register_x86_hpp patch-hotspot_src_cpu_zero_vm_register_zero_hpp patch-hotspot_src_share_vm_c1_c1_LIR_hpp patch-hotspot_src_share_vm_code_vmreg_hpp patch-hotspot_src_share_vm_oops_metadata_hpp Log message: Update to 8u322 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-8/?quarter=012022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-01-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/02/06 17:15:58 Modified files: devel/jdk/17 : Makefile distinfo Removed files: devel/jdk/17/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-src_hotspot_cpu_aarch64_register_aarch64_hpp patch-src_hotspot_cpu_x86_register_x86_hpp patch-src_hotspot_share_c1_c1_LIR_hpp patch-src_hotspot_share_code_vmreg_hpp patch-src_hotspot_share_oops_metadata_hpp Log message: Update to 17.0.2 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?quarter=012022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-01-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/02/06 17:15:31 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/11/pkg: PLIST Removed files: devel/jdk/11/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-src_hotspot_cpu_aarch64_aarch64_ad patch-src_hotspot_cpu_aarch64_assembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_assembler_aarch64_hpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_hpp patch-src_hotspot_cpu_aarch64_register_aarch64_hpp patch-src_hotspot_cpu_x86_register_x86_hpp patch-src_hotspot_share_c1_c1_LIR_hpp patch-src_hotspot_share_code_vmreg_hpp patch-src_hotspot_share_oops_metadata_hpp Log message: Update to 11.0.14 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?quarter=012022=allissues https://openjdk.java.net/groups/vulnerability/advisories/2022-01-18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/08 15:41:06 Modified files: devel/jdk/1.8 : Makefile distinfo Added files: devel/jdk/1.8/patches: patch-hotspot_make_bsd_makefiles_gcc_make patch-hotspot_src_cpu_aarch64_vm_register_aarch64_hpp patch-hotspot_src_cpu_x86_vm_register_x86_hpp patch-hotspot_src_cpu_zero_vm_register_zero_hpp patch-hotspot_src_share_vm_c1_c1_LIR_hpp patch-hotspot_src_share_vm_code_vmreg_hpp patch-hotspot_src_share_vm_oops_metadata_hpp Log message: Clang 13 doesn't like when you use 'this' as tagged pointer. It optimizes away the bit twiddling. Work around this by setting all accessor methods to no-inline and where that wasn't sufficient, reduce optimization level to -O1 to prevent clang from optimizing away code that is needed. Also remove ant as build depend. This was never needed and mistakenly copied from the 1.7 jdk port.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/08 08:05:30 Modified files: devel/jdk/17 : Makefile Added files: devel/jdk/17/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk patch-src_hotspot_cpu_aarch64_register_aarch64_hpp patch-src_hotspot_cpu_x86_register_x86_hpp patch-src_hotspot_share_c1_c1_LIR_hpp patch-src_hotspot_share_code_vmreg_hpp patch-src_hotspot_share_oops_metadata_hpp Log message: Clang 13 doesn't like when you use 'this' as tagged pointer. It optimizes away the bit twiddling. Work around this by setting all accessor methods to no-inline and where that wasn't sufficient, reduce optimization level to -O1 to prevent clang from optimizing away code that is needed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/05 16:15:48 Modified files: devel/jdk/11 : Makefile devel/jdk/11/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk Added files: devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_register_aarch64_hpp patch-src_hotspot_cpu_x86_register_x86_hpp patch-src_hotspot_share_c1_c1_LIR_hpp patch-src_hotspot_share_code_vmreg_hpp patch-src_hotspot_share_oops_metadata_hpp Log message: Clang 13 doesn't like when you use 'this' as tagged pointer. It optimizes away the bit twiddling. Work around this by setting all accessor methods to no-inline and where that wasn't sufficient, reduce optimization level to -O1 to prevent clang from optimizing away code that is needed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/30 10:02:01 Modified files: x11/gnome/gjs : Makefile Log message: Use ports-clang to fix build on gcc arch. okay kmos@
Re: sparc64 bulk build report
On Sat, 2021-11-20 at 21:39 -0700, k...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/sparc64/2021-11-18/x11/gnome/gjs.log
cc1plus: warning: libgjs-jsapi.a.p/gjs_pch.hh.gch: had text segment at
different address
cc1plus: error: one or more PCH files were found, but they were invalid
Disabling precompiled headers reveals another gcc 8.4.0 issue with
the cxx11 abi_tag not being applied consistently and causing link
errors. No amount of fiddling with trying to get gcc to apply the
tag where it was missing worked for me, but switching to ports
clang works. okay?
Index: Makefile
===
RCS file: /cvs/ports/x11/gnome/gjs/Makefile,v
retrieving revision 1.99
diff -u -p -u -r1.99 Makefile
--- Makefile25 Oct 2021 14:48:37 - 1.99
+++ Makefile23 Nov 2021 21:58:48 -
@@ -25,7 +25,7 @@ MODULES= devel/meson \
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-COMPILER= base-clang ports-gcc
+COMPILER= base-clang ports-clang
MODPY_RUNDEP= No
MODPY_BUILDDEP= No
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/18 08:58:32 Removed files: devel/jdk/16 : Makefile distinfo devel/jdk/16/files: cacerts devel/jdk/16/patches: patch-make_common_NativeCompilation_gmk devel/jdk/16/pkg: DESCR PFRAG.aot PFRAG.ci PLIST README Log message: Remove jdk-16.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/12 16:05:30 Modified files: sysutils/polkit: Makefile Added files: sysutils/polkit/patches: patch-meson_build Log message: Fix meson config check for whether setnetgrent has a return value. Fixes build on sparc64. okay sthen@
Re: sparc64 bulk build report
On Nov 11, 2021, at 7:22 PM, Stuart Henderson wrote:
>
> On 2021/11/11 15:31, k...@openbsd.org wrote:
>> http://build-failures.rhaalovely.net/sparc64/2021-11-09/sysutils/polkit.log
>
> I don't see how to fix it properly in meson.build, but here is the problem,
> this is detected incorrectly with ports-gcc,
>
> Checking if "setnetgrent return support" : compiles: YES
>
> Should be NO.
>
> Looking in meson.build
>
> 150
> 151 # Check whether setnetgrent has a return value
> 152 config_h.set('HAVE_NETGROUP_H', cc.has_header('netgroup.h'))
> 153
>
> this is detecting netgroup.h and is setting it in config.h, but it is
> *not* defining HAVE_NETGROUP_H when it compiles the following test
>
> 154 setnetgrent_return_src = '''
> 155 #include
> 156 #ifdef HAVE_NETGROUP_H
> 157 #include
> 158 #else
> 159 #include
> 160 #endif
> 161 int main() {
> 162 int r = setnetgrent (NULL);
> 163 };
> 164 '''
> 165
> 166 config_h.set('HAVE_SETNETGRENT_RETURN',
> cc.compiles(setnetgrent_return_src, name: 'setnetgrent return support'))
>
> The difference between the compilers is that gcc returns
>
> warning: implicit declaration of function 'setnetgrent'; did you mean
> 'setnetent'? [-Wimplicit-function-declaration]
>
> whereas clang gives
>
> error: implicit declaration of function 'setnetgrent' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
> so the test compile is giving wrong results, so it takes the wrong
> ifdef path resulting in the build failure
>
> ../polkit-0.120/src/polkitbackend/polkitbackendinteractiveauthority.c:2239:7:
> error: void value not ignored as it ought to be
>
> Bodging it with
>
> 166 config_h.set('HAVE_SETNETGRENT_RETURN',
> cc.compiles(setnetgrent_return_src, name: 'setnetgrent return support', args:
> '-DHAVE_NETGROUP_H'))
>
> does work well enough for OpenBSD but obviously not correct ..
>
Here’s a cleaner version then the one I previously sent. Okay?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/polkit/Makefile,v
retrieving revision 1.88
diff -u -p -u -r1.88 Makefile
--- Makefile30 Oct 2021 14:26:23 - 1.88
+++ Makefile12 Nov 2021 17:56:16 -
@@ -3,6 +3,7 @@
COMMENT= framework for granting privileged operations to users
DISTNAME= polkit-0.120
+REVISION= 0
SHARED_LIBS += polkit-gobject-1 2.0 # 0.0.0
SHARED_LIBS += polkit-agent-12.0 # 0.0.0
Index: patches/patch-meson_build
===
RCS file: patches/patch-meson_build
diff -N patches/patch-meson_build
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-meson_build 12 Nov 2021 17:56:16 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+Fix check for whether setnetgrent has a return value
+
+Index: meson.build
+--- meson.build.orig
meson.build
+@@ -163,8 +163,11 @@ setnetgrent_return_src = '''
+ };
+ '''
+
+-config_h.set('HAVE_SETNETGRENT_RETURN', cc.compiles(setnetgrent_return_src,
name: 'setnetgrent return support'))
+-
++if config_h.get('HAVE_NETGROUP_H')
++ config_h.set('HAVE_SETNETGRENT_RETURN', cc.compiles(setnetgrent_return_src,
name: 'setnetgrent return support', args: '-DHAVE_NETGROUP_H'))
++else
++ config_h.set('HAVE_SETNETGRENT_RETURN', cc.compiles(setnetgrent_return_src,
name: 'setnetgrent return support'))
++endif
+ # Select wether to use libsystemd-login, libelogind or ConsoleKit for session
tracking
+ session_tracking = get_option('session_tracking')
+ enable_logind = (session_tracking != 'ConsoleKit’)
polkit.setnetgrent.diff
Description: Binary data
Re: sparc64 bulk build report
On Nov 11, 2021, at 7:22 PM, Stuart Henderson wrote:
>
> On 2021/11/11 15:31, k...@openbsd.org wrote:
>> http://build-failures.rhaalovely.net/sparc64/2021-11-09/sysutils/polkit.log
>
> I don't see how to fix it properly in meson.build, but here is the problem,
> this is detected incorrectly with ports-gcc,
>
> Checking if "setnetgrent return support" : compiles: YES
>
> Should be NO.
>
> Looking in meson.build
>
> 150
> 151 # Check whether setnetgrent has a return value
> 152 config_h.set('HAVE_NETGROUP_H', cc.has_header('netgroup.h'))
> 153
>
> this is detecting netgroup.h and is setting it in config.h, but it is
> *not* defining HAVE_NETGROUP_H when it compiles the following test
>
> 154 setnetgrent_return_src = '''
> 155 #include
> 156 #ifdef HAVE_NETGROUP_H
> 157 #include
> 158 #else
> 159 #include
> 160 #endif
> 161 int main() {
> 162 int r = setnetgrent (NULL);
> 163 };
> 164 '''
> 165
> 166 config_h.set('HAVE_SETNETGRENT_RETURN',
> cc.compiles(setnetgrent_return_src, name: 'setnetgrent return support'))
>
> The difference between the compilers is that gcc returns
>
> warning: implicit declaration of function 'setnetgrent'; did you mean
> 'setnetent'? [-Wimplicit-function-declaration]
>
> whereas clang gives
>
> error: implicit declaration of function 'setnetgrent' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
> so the test compile is giving wrong results, so it takes the wrong
> ifdef path resulting in the build failure
>
> ../polkit-0.120/src/polkitbackend/polkitbackendinteractiveauthority.c:2239:7:
> error: void value not ignored as it ought to be
>
> Bodging it with
>
> 166 config_h.set('HAVE_SETNETGRENT_RETURN',
> cc.compiles(setnetgrent_return_src, name: 'setnetgrent return support', args:
> '-DHAVE_NETGROUP_H'))
>
> does work well enough for OpenBSD but obviously not correct ..
>
I believe the attached diff is a correct fix for this. Works on sparc64 and
amd64.
Sorry its an attachment (mua on macosx doesn’t inline patches correctly I
believe).
-Kurt
polkit.setnetgrent.diff
Description: Binary data
Re: sparc64 bulk build report
On Nov 9, 2021, at 3:09 AM, k...@openbsd.org wrote: > > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Sun Nov 7 13:24:58 MST 2021 > Finished: Tue Nov 9 01:09:33 MST 2021 > Duration: 1 Days 11 hours 45 minutes > > Built using OpenBSD 7.0-current (GENERIC.MP) #1036: Sat Nov 6 23:08:50 MDT > 2021 > > Built 7885 packages > > Number of packages built each day: > Nov 7: 6907 > Nov 8: 974 > Nov 9: 4 > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2021-11-07/summary.log > > Build failures: 18 > http://build-failures.rhaalovely.net/sparc64/2021-11-07/archivers/fuse-zip.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/astro/py-astropy,python3.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/audio/ncmpcpp.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/databases/pspg.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/devel/avr/gcc.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/devel/harfbuzz.log It looks like release 3.1.1 of harfbuzz has this fixed: https://github.com/harfbuzz/harfbuzz/issues/3283 > http://build-failures.rhaalovely.net/sparc64/2021-11-07/emulators/openmsx.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/games/colobot/colobot.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/games/egoboo.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/games/godot.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/graphics/openexr.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/lang/clazy.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/net/gupnp/av.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/net/pmacct,postgresql.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/sysutils/polkit.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/textproc/docbook-utils.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/www/nextcloud_notify_push.log > http://build-failures.rhaalovely.net/sparc64/2021-11-07/x11/gnome/gjs.log >
Re: LLVM 13 ports build failures (2021-11-04)
On Nov 8, 2021, at 6:41 PM, Kurt Miller wrote: > > On Nov 8, 2021, at 4:48 PM, Christian Weisgerber wrote: >> >> Jeremie Courreges-Anglas: >> >>> Those are two approaches to get past this failure, but I suspect that >>> the root cause is just a bug / limitation introduced in this llvm >>> release. The approach taken by libintl looks reasonable to me, >> >> I'm looking at security/pinentry as an example case, and it's a >> headscratcher. >> >> libglib-2.0.so is loaded first, and it has undefined references to >> pthread_mutexattr_*() as well as a DT_NEEDED for libpthread.so. >> libintl.so with its weak references to pthread_mutexattr_*() comes >> later. How can pthread_mutexattr_*() end up as undefined there? > > jca@ original analysis points to ld.lld not being smart enough > to deal with that case. That appears to be the case and it really > should be treated as a weak symbol, not an undefined symbol > for libintl. > >> IIRC, the last lld update saw a change where libxxx with DT_NEEDED >> for Libby now meant that only libxxx would see the symbols from >> libyyy. If other object files reference symbols from libyyy, an >> explicit -lyyy is needed. So that would explain why libintl doesn't >> see the libpthread that is pulled in by libglib. But in that case >> libintl should fall back to the weak symbol reference. > > I checked our runtime linker and libintl’s weak symbols for > pthread_mutexattr_* are resolved at runtime by the libpthread > that is linked in indirectly via glib. Since that is the case we might > as well link the affected ports (not libintl.so, the ports with linking > errors) with -pthread since they already link indirectly to pthreads. > > I think disabling --no-allow-shlib-undefined is probably not justified > given the small number of ports effected so far. > Or maybe cleaner would be to just disable the buggy ld.lld check on the ports that fail to link by adding -Wl,--allow-shlib-undefined to LDFLAGS. -Kurt
Re: LLVM 13 ports build failures (2021-11-04)
On Nov 8, 2021, at 4:48 PM, Christian Weisgerber wrote: > > Jeremie Courreges-Anglas: > >> Those are two approaches to get past this failure, but I suspect that >> the root cause is just a bug / limitation introduced in this llvm >> release. The approach taken by libintl looks reasonable to me, > > I'm looking at security/pinentry as an example case, and it's a > headscratcher. > > libglib-2.0.so is loaded first, and it has undefined references to > pthread_mutexattr_*() as well as a DT_NEEDED for libpthread.so. > libintl.so with its weak references to pthread_mutexattr_*() comes > later. How can pthread_mutexattr_*() end up as undefined there? jca@ original analysis points to ld.lld not being smart enough to deal with that case. That appears to be the case and it really should be treated as a weak symbol, not an undefined symbol for libintl. > IIRC, the last lld update saw a change where libxxx with DT_NEEDED > for Libby now meant that only libxxx would see the symbols from > libyyy. If other object files reference symbols from libyyy, an > explicit -lyyy is needed. So that would explain why libintl doesn't > see the libpthread that is pulled in by libglib. But in that case > libintl should fall back to the weak symbol reference. I checked our runtime linker and libintl’s weak symbols for pthread_mutexattr_* are resolved at runtime by the libpthread that is linked in indirectly via glib. Since that is the case we might as well link the affected ports (not libintl.so, the ports with linking errors) with -pthread since they already link indirectly to pthreads. I think disabling --no-allow-shlib-undefined is probably not justified given the small number of ports effected so far. -Kurt
Re: LLVM 13 ports build failures (2021-11-04)
> On Nov 5, 2021, at 5:00 PM, Christian Weisgerber wrote: > > I ran another amd64 bulk build with base clang updated to LLVM 13. > I also put in a tentative fix for security/nss. > > Failure logs: > http://build-failures.rhaalovely.net/amd64-clang/2021-11-04/ > > Some very basic triage below. The single biggest problem is linker > failures of this kind: > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to > pthread_mutexattr_init [--no-allow-shlib-undefined] > > The most criticial individual port failure is security/pinentry, > which takes out security/gnupg, which prevents hundreds of ports > from being built. > > audio/mpd C++ > audio/scmpc libintl.so.7.0: undefined reference > cad/pcb libintl.so.7.0: undefined reference > chinese/c2t address of register variable requested > devel/libdsm-Werror breaks pthread autoconf test > devel/libgtop2 libintl.so.7.0: undefined reference > devel/qbs qbs segfault > devel/xtensa-lx106-elf/binutils -Werror,-Wunused-but-set-variable > editors/vim,gtk3,lualibintl.so.7.0: undefined reference > games/dopewars libintl.so.7.0: undefined reference > games/eduke32 LLVM ERROR: out of memory > games/lwjgl3java segfault I committed a fix for the lwjgl3 java segfault in jdk-11. > games/multimc -Werror,-Wunused-but-set-variable > games/nbloodLLVM ERROR: out of memory > graphics/gimp/stablemissing dependency glib >= 2.56.2 > graphics/vulkan-validation-layers -Werror,-Wdeprecated-copy > inputmethods/fcitx libintl.so.7.0: undefined reference > lang/dmdcan't load library 'libc++abi.so.5.0' > lang/gambit killed: build stuck for 60mn > lang/libv8 mksnapshot segfault > mail/neomuttUnable to find KyotoCabinet > misc/posixtestsuite packaging: .test does not exist > net/gtk-gnutellaCannot compile against GLib > security/encfs C++ > security/pinentry libintl.so.7.0: undefined reference > sysutils/curlftpfs use of undeclared identifier > sysutils/login_oath -Werror,-Wunused-but-set-variable > textproc/apertium C++ > www/libwebsockets -Werror,-Wunused-but-set-variable > www/tor-browser/browser -Werror,-Wunused-but-set-variable > x11/awesome libexecinfo.so.3.0: undefined reference > x11/fvwm2 libintl.so.7.0: undefined reference > x11/jwm libintl.so.7.0: undefined reference > x11/mate/panel libintl.so.7.0: undefined reference > x11/parcellite packaging: parcellite.mo does not exist > x11/qt5/qtlocation C++ > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/08 14:42:16 Modified files: devel/jdk/11 : Makefile Added files: devel/jdk/11/patches: patch-make_hotspot_lib_JvmOverrideFiles_gmk Log message: Fix a segfault seen with clang 13 in synchronizer.cpp by reducing optimization level for it.
Re: UPDATE: java/gradle
On Nov 8, 2021, at 2:30 AM, Rafael Sadowski wrote:
>
> Update gradle to 7.2.
>
> I have noticed that gradle will use JDK 11 if 1.8,11,17 are present, so I
> guess we can switch to MODJAVA_VER 11?
>
I have the same comment sthen@ had for the maven update. If this runs with
1.8 and 11 the version string should stay as 1.8+.
Do you have /usr/local/jdk-11/bin in your path?
> OK?
>
> diff --git a/java/gradle/Makefile b/java/gradle/Makefile
> index 5dc9ce0d4b1..1ebeb950108 100644
> --- a/java/gradle/Makefile
> +++ b/java/gradle/Makefile
> @@ -2,9 +2,8 @@
>
> COMMENT = build automation tool
>
> -DISTNAME = gradle-6.7
> +DISTNAME = gradle-7.2
> EXTRACT_SUFX =-bin.zip
> -REVISION = 0
>
> CATEGORIES = java
>
> @@ -18,7 +17,7 @@ PERMIT_PACKAGE =Yes
> MASTER_SITES =https://services.gradle.org/distributions/
>
> MODULES = java
> -MODJAVA_VER =1.8+
> +MODJAVA_VER =11
>
> NO_BUILD =Yes
> NO_TEST = Yes
> diff --git a/java/gradle/distinfo b/java/gradle/distinfo
> index d7c3fd3837f..3633036615b 100644
> --- a/java/gradle/distinfo
> +++ b/java/gradle/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (gradle-6.7-bin.zip) = itV3WQGakjPcfcTRpTDO/hCdwSIADVf35iP4z0up38Q=
> -SIZE (gradle-6.7-bin.zip) = 102804263
> +SHA256 (gradle-7.2-bin.zip) = 9YFwmpw16cuS4W9YXSxLyZsrGl+F0rrb09xr/1nh5t0=
> +SIZE (gradle-7.2-bin.zip) = 114352742
> diff --git a/java/gradle/pkg/PLIST b/java/gradle/pkg/PLIST
> index 6dfa4c879c0..7c50c41b598 100644
> --- a/java/gradle/pkg/PLIST
> +++ b/java/gradle/pkg/PLIST
> @@ -11,26 +11,30 @@ share/java/gradle/bin/gradle.bat
> share/java/gradle/init.d/
> share/java/gradle/init.d/readme.txt
> share/java/gradle/lib/
> -share/java/gradle/lib/annotations-13.0.jar
> -share/java/gradle/lib/ant-1.10.8.jar
> -share/java/gradle/lib/ant-launcher-1.10.8.jar
> -share/java/gradle/lib/asm-7.3.1.jar
> -share/java/gradle/lib/asm-analysis-7.3.1.jar
> -share/java/gradle/lib/asm-commons-7.3.1.jar
> -share/java/gradle/lib/asm-tree-7.3.1.jar
> -share/java/gradle/lib/commons-compress-1.19.jar
> +share/java/gradle/lib/annotations-20.1.0.jar
> +share/java/gradle/lib/ant-1.10.9.jar
> +share/java/gradle/lib/ant-antlr-1.10.9.jar
> +share/java/gradle/lib/ant-junit-1.10.9.jar
> +share/java/gradle/lib/ant-launcher-1.10.9.jar
> +share/java/gradle/lib/antlr4-runtime-4.7.2.jar
> +share/java/gradle/lib/asm-9.1.jar
> +share/java/gradle/lib/asm-analysis-9.1.jar
> +share/java/gradle/lib/asm-commons-9.1.jar
> +share/java/gradle/lib/asm-tree-9.1.jar
> +share/java/gradle/lib/commons-compress-1.20.jar
> share/java/gradle/lib/commons-io-2.6.jar
> share/java/gradle/lib/commons-lang-2.6.jar
> share/java/gradle/lib/failureaccess-1.0.1.jar
> -share/java/gradle/lib/fastutil-8.3.0-min.jar
> -share/java/gradle/lib/file-events-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-linux-aarch64-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-linux-amd64-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-osx-amd64-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-windows-amd64-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-windows-amd64-min-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-windows-i386-0.22-milestone-8.jar
> -share/java/gradle/lib/file-events-windows-i386-min-0.22-milestone-8.jar
> +share/java/gradle/lib/fastutil-8.5.2-min.jar
> +share/java/gradle/lib/file-events-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-linux-aarch64-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-linux-amd64-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-osx-aarch64-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-osx-amd64-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-windows-amd64-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-windows-amd64-min-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-windows-i386-0.22-milestone-21.jar
> +share/java/gradle/lib/file-events-windows-i386-min-0.22-milestone-21.jar
> share/java/gradle/lib/gradle-api-metadata${GRADLE_JAR}
> share/java/gradle/lib/gradle-base-annotations${GRADLE_JAR}
> share/java/gradle/lib/gradle-base-services${GRADLE_JAR}
> @@ -47,8 +51,10 @@ share/java/gradle/lib/gradle-core${GRADLE_JAR}
> share/java/gradle/lib/gradle-core-api${GRADLE_JAR}
> share/java/gradle/lib/gradle-execution${GRADLE_JAR}
> share/java/gradle/lib/gradle-file-collections${GRADLE_JAR}
> +share/java/gradle/lib/gradle-file-temp${GRADLE_JAR}
> share/java/gradle/lib/gradle-file-watching${GRADLE_JAR}
> share/java/gradle/lib/gradle-files${GRADLE_JAR}
> +share/java/gradle/lib/gradle-functional${GRADLE_JAR}
> share/java/gradle/lib/gradle-hashing${GRADLE_JAR}
> share/java/gradle/lib/gradle-installation-beacon${GRADLE_JAR}
> share/java/gradle/lib/gradle-jvm-services${GRADLE_JAR}
> @@ -62,6 +68,7 @@ share/java/gradle/lib/gradle-model-groovy${GRADLE_JAR}
> share/java/gradle/lib/gradle-native${GRADLE_JAR}
>
Re: LLVM 13 ports build failures (2021-11-04)
On Nov 5, 2021, at 5:00 PM, Christian Weisgerber wrote: > > I ran another amd64 bulk build with base clang updated to LLVM 13. > I also put in a tentative fix for security/nss. > > Failure logs: > http://build-failures.rhaalovely.net/amd64-clang/2021-11-04/ > > Some very basic triage below. The single biggest problem is linker > failures of this kind: > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to > pthread_mutexattr_init [--no-allow-shlib-undefined] libintl has some weak references to pthread’s functions: llvm13$ nm /usr/local/lib/libintl.so.7.0 | grep pthread 3f80 t pthread_atfork W pthread_cond_broadcast W pthread_cond_destroy W pthread_cond_init W pthread_cond_signal W pthread_cond_wait W pthread_mutex_destroy W pthread_mutex_init W pthread_mutex_lock W pthread_mutex_unlock W pthread_mutexattr_destroy W pthread_mutexattr_gettype W pthread_mutexattr_init W pthread_mutexattr_settype pthread_cond_* and pthread_mutex_* were moved into libc a while ago: https://github.com/openbsd/src/commit/a5511fa9f431600dbd6dc2b46fc4e6b73e7d239c However, pthread_mutexattr_* was not and requires -pthread to pick it up. These ports that are failing will need to link with -pthread or alternatively we need to move pthread_mutexattr_* from libpthread to libc. That does make some sense as pthread_condattr_* was moved over with pthread_cond_*, but pthread_mutexattr_* was not moved over with pthread_mutex_*. > > The most criticial individual port failure is security/pinentry, > which takes out security/gnupg, which prevents hundreds of ports > from being built. > > audio/mpd C++ > audio/scmpc libintl.so.7.0: undefined reference > cad/pcb libintl.so.7.0: undefined reference > chinese/c2t address of register variable requested > devel/libdsm-Werror breaks pthread autoconf test > devel/libgtop2 libintl.so.7.0: undefined reference > devel/qbs qbs segfault > devel/xtensa-lx106-elf/binutils -Werror,-Wunused-but-set-variable > editors/vim,gtk3,lualibintl.so.7.0: undefined reference > games/dopewars libintl.so.7.0: undefined reference > games/eduke32 LLVM ERROR: out of memory > games/lwjgl3java segfault > games/multimc -Werror,-Wunused-but-set-variable > games/nbloodLLVM ERROR: out of memory > graphics/gimp/stablemissing dependency glib >= 2.56.2 > graphics/vulkan-validation-layers -Werror,-Wdeprecated-copy > inputmethods/fcitx libintl.so.7.0: undefined reference > lang/dmdcan't load library 'libc++abi.so.5.0' > lang/gambit killed: build stuck for 60mn > lang/libv8 mksnapshot segfault > mail/neomuttUnable to find KyotoCabinet > misc/posixtestsuite packaging: .test does not exist > net/gtk-gnutellaCannot compile against GLib > security/encfs C++ > security/pinentry libintl.so.7.0: undefined reference > sysutils/curlftpfs use of undeclared identifier > sysutils/login_oath -Werror,-Wunused-but-set-variable > textproc/apertium C++ > www/libwebsockets -Werror,-Wunused-but-set-variable > www/tor-browser/browser -Werror,-Wunused-but-set-variable > x11/awesome libexecinfo.so.3.0: undefined reference > x11/fvwm2 libintl.so.7.0: undefined reference > x11/jwm libintl.so.7.0: undefined reference > x11/mate/panel libintl.so.7.0: undefined reference > x11/parcellite packaging: parcellite.mo does not exist > x11/qt5/qtlocation C++ > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/07 12:35:33 Modified files: graphics/cairo : Makefile Log message: Add LDFLAGS="-L/usr/X11R6/lib" to configure env to fix the build on ld.bfd systems. It appears ld.bfd has an issue with libs specified with full paths. okay ajacoutot@
Re: [sparc64] Fix build of graphics/cairo
On Nov 7, 2021, at 12:14 PM, Kurt Miller wrote:
>
> On Nov 7, 2021, at 11:05 AM, Antoine Jacoutot wrote:
>>
>> On Sun, Nov 07, 2021 at 10:51:53AM -0500, Kurt Miller wrote:
>>> On Nov 5, 2021, at 3:34 PM, Antoine Jacoutot wrote:
>>>>
>>>> On Fri, Nov 05, 2021 at 03:19:12PM -0400, Kurt Mosiejczuk wrote:
>>>>> On Fri, Nov 05, 2021 at 07:59:35PM +0100, Antoine Jacoutot wrote:
>>>>>> On Fri, Nov 05, 2021 at 01:43:50PM -0400, Kurt Mosiejczuk wrote:
>>>>>>> The switch to building with meson for the update to 1.17.4 did not get
>>>>>>> along with sparc64 at all. Which knocks out a large portion of the tree.
>>>>>
>>>>>>> Switching back to using autotools (and updating the PLIST) fixes the
>>>>>>> build
>>>>>>> on sparc64 (and doesn't break it on amd64).
>>>>>
>>>>>>> ok?
>>>>>
>>>>>> What's the failure?
>>>>>
>>>>> http://build-failures.rhaalovely.net/sparc64/2021-11-02/graphics/cairo.log
>>>>>
>>>>> In file included from ../cairo-1.17.4/src/cairo-xlib-private.h:40,
>>>>> from ../cairo-1.17.4/src/cairo-xlib-display.c:40:
>>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:106: error: redefinition
>>>>> of 'struct _XLinearGradient'
>>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:115: error: redefinition
>>>>> of 'struct _XCircle'
>>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:120: error: redefinition
>>>>> of 'struct _XRadialGradient'
>>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:129: error: redefinition
>>>>> of 'struct _XConicalGradient'
>>>>>
>>>>> --Kurt
>>>>
>>>> Can you find out why libExt failed?
>>>>
>>>> Checking if "shmctl IPC_RMID allowes subsequent attaches" with
>>>> dependencies x11, xext runs: DID NOT COMPILE
>>>>
>>>> Also please try with llvm.
>>>
>>> I took a look at this a bit. Here’s what I found. The meson configure stage
>>> is
>>> failing many checks that lead to an improper configuration and then results
>>> in the the build failure above.
>>>
>>> It looks to me like the root cause is a binutils-2.17 ld bug. Meson builds
>>> its
>>> test programs with full paths to certain libraries and ld fails to link.
>>>
>>> For example, here is the alarm test program:
>>>
>>> #define alarm meson_disable_define_of_alarm
>>>
>>> #include
>>> #undef alarm
>>>
>>> #ifdef __cplusplus
>>> extern "C"
>>> #endif
>>> char alarm (void);
>>>
>>> #if defined __stub_alarm || defined __stub___alarm
>>> fail fail fail this function is not going to work
>>> #endif
>>>
>>> int main(void) {
>>> return alarm ();
>>> }
>>>
>>> Its compiled and linked with the following command:
>>>
>>> cc -I/usr/local/include -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include
>>> -I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng16
>>> -I/usr/local/include/lzo testfile.c -o output.exe -O2 -pipe -g
>>> -D_FILE_OFFSET_BITS=64 -O0 -Wl,--start-group -lm
>>> /usr/local/lib/liblzo2.so.1.0 -lz /usr/local/lib/libpng.so.18.0
>>> /usr/lib/libz.so.6.0 /usr/X11R6/lib/libfontconfig.so.13.0
>>> /usr/X11R6/lib/libfreetype.so.30.0 /usr/X11R6/lib/libX11.so.17.1
>>> /usr/X11R6/lib/libXext.so.13.0 /usr/X11R6/lib/libXrender.so.6.0
>>> /usr/X11R6/lib/libxcb.so.4.1 /usr/X11R6/lib/libxcb-render.so.1.1
>>> /usr/X11R6/lib/libxcb-shm.so.1.1 /usr/X11R6/lib/libpixman-1.so.40.0
>>> -Wl,--end-group
>>>
>>> And results in these linking errors:
>>>
>>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: sprintf() is often misused,
>>> please use snprintf()
>>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: strcpy() is almost always
>>> misused, please use strlcpy()
>>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: strcat() is almost always
>>> misused, please use strlcat()
>>> /usr/bin/ld: warning: libX11.so.17.1, needed by
>>> /usr/X11R6/lib/libXext.so.13.0, not found (try using -rpath or -rpath-link)
>>> /usr/bin/ld: w
Re: [sparc64] Fix build of graphics/cairo
On Nov 7, 2021, at 11:05 AM, Antoine Jacoutot wrote:
>
> On Sun, Nov 07, 2021 at 10:51:53AM -0500, Kurt Miller wrote:
>> On Nov 5, 2021, at 3:34 PM, Antoine Jacoutot wrote:
>>>
>>> On Fri, Nov 05, 2021 at 03:19:12PM -0400, Kurt Mosiejczuk wrote:
>>>> On Fri, Nov 05, 2021 at 07:59:35PM +0100, Antoine Jacoutot wrote:
>>>>> On Fri, Nov 05, 2021 at 01:43:50PM -0400, Kurt Mosiejczuk wrote:
>>>>>> The switch to building with meson for the update to 1.17.4 did not get
>>>>>> along with sparc64 at all. Which knocks out a large portion of the tree.
>>>>
>>>>>> Switching back to using autotools (and updating the PLIST) fixes the
>>>>>> build
>>>>>> on sparc64 (and doesn't break it on amd64).
>>>>
>>>>>> ok?
>>>>
>>>>> What's the failure?
>>>>
>>>> http://build-failures.rhaalovely.net/sparc64/2021-11-02/graphics/cairo.log
>>>>
>>>> In file included from ../cairo-1.17.4/src/cairo-xlib-private.h:40,
>>>>from ../cairo-1.17.4/src/cairo-xlib-display.c:40:
>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:106: error: redefinition
>>>> of 'struct _XLinearGradient'
>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:115: error: redefinition
>>>> of 'struct _XCircle'
>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:120: error: redefinition
>>>> of 'struct _XRadialGradient'
>>>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:129: error: redefinition
>>>> of 'struct _XConicalGradient'
>>>>
>>>> --Kurt
>>>
>>> Can you find out why libExt failed?
>>>
>>> Checking if "shmctl IPC_RMID allowes subsequent attaches" with dependencies
>>> x11, xext runs: DID NOT COMPILE
>>>
>>> Also please try with llvm.
>>
>> I took a look at this a bit. Here’s what I found. The meson configure stage
>> is
>> failing many checks that lead to an improper configuration and then results
>> in the the build failure above.
>>
>> It looks to me like the root cause is a binutils-2.17 ld bug. Meson builds
>> its
>> test programs with full paths to certain libraries and ld fails to link.
>>
>> For example, here is the alarm test program:
>>
>>#define alarm meson_disable_define_of_alarm
>>
>>#include
>>#undef alarm
>>
>>#ifdef __cplusplus
>>extern "C"
>>#endif
>>char alarm (void);
>>
>>#if defined __stub_alarm || defined __stub___alarm
>>fail fail fail this function is not going to work
>>#endif
>>
>>int main(void) {
>> return alarm ();
>>}
>>
>> Its compiled and linked with the following command:
>>
>> cc -I/usr/local/include -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include
>> -I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng16
>> -I/usr/local/include/lzo testfile.c -o output.exe -O2 -pipe -g
>> -D_FILE_OFFSET_BITS=64 -O0 -Wl,--start-group -lm
>> /usr/local/lib/liblzo2.so.1.0 -lz /usr/local/lib/libpng.so.18.0
>> /usr/lib/libz.so.6.0 /usr/X11R6/lib/libfontconfig.so.13.0
>> /usr/X11R6/lib/libfreetype.so.30.0 /usr/X11R6/lib/libX11.so.17.1
>> /usr/X11R6/lib/libXext.so.13.0 /usr/X11R6/lib/libXrender.so.6.0
>> /usr/X11R6/lib/libxcb.so.4.1 /usr/X11R6/lib/libxcb-render.so.1.1
>> /usr/X11R6/lib/libxcb-shm.so.1.1 /usr/X11R6/lib/libpixman-1.so.40.0
>> -Wl,--end-group
>>
>> And results in these linking errors:
>>
>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: sprintf() is often misused,
>> please use snprintf()
>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: strcpy() is almost always
>> misused, please use strlcpy()
>> /usr/X11R6/lib/libfontconfig.so.13.0: warning: strcat() is almost always
>> misused, please use strlcat()
>> /usr/bin/ld: warning: libX11.so.17.1, needed by
>> /usr/X11R6/lib/libXext.so.13.0, not found (try using -rpath or -rpath-link)
>> /usr/bin/ld: warning: libXau.so.10.0, needed by
>> /usr/X11R6/lib/libxcb.so.4.1, not found (try using -rpath or -rpath-link)
>> /usr/bin/ld: warning: libXdmcp.so.11.0, needed by
>> /usr/X11R6/lib/libxcb.so.4.1, not found (try using -rpath or -rpath-link)
>> /usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XdmcpWrap'
>> /usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XauGetBestAuthByAddr'
>> /usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XauDisposeAuth’
>>
>> Note the warning lines about not finding libs that are clearly in the list of
>> libs to link but using full paths instead of -llibX11 for example.
>> All of the failing configure tests are failing in the same way.
>
> Missing LDFLAGS -L/usr/X11R6/lib ?
Yes adding -L/usr/X11R6/lib allows them to link, but the question is
why is it necessary when the libs ld claims it can’t find are explicitly
listed in the list of libs with full paths to find them?
-Kurt
Re: [sparc64] Fix build of graphics/cairo
On Nov 5, 2021, at 3:34 PM, Antoine Jacoutot wrote:
>
> On Fri, Nov 05, 2021 at 03:19:12PM -0400, Kurt Mosiejczuk wrote:
>> On Fri, Nov 05, 2021 at 07:59:35PM +0100, Antoine Jacoutot wrote:
>>> On Fri, Nov 05, 2021 at 01:43:50PM -0400, Kurt Mosiejczuk wrote:
The switch to building with meson for the update to 1.17.4 did not get
along with sparc64 at all. Which knocks out a large portion of the tree.
>>
Switching back to using autotools (and updating the PLIST) fixes the build
on sparc64 (and doesn't break it on amd64).
>>
ok?
>>
>>> What's the failure?
>>
>> http://build-failures.rhaalovely.net/sparc64/2021-11-02/graphics/cairo.log
>>
>> In file included from ../cairo-1.17.4/src/cairo-xlib-private.h:40,
>> from ../cairo-1.17.4/src/cairo-xlib-display.c:40:
>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:106: error: redefinition of
>> 'struct _XLinearGradient'
>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:115: error: redefinition of
>> 'struct _XCircle'
>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:120: error: redefinition of
>> 'struct _XRadialGradient'
>> ../cairo-1.17.4/src/cairo-xlib-xrender-private.h:129: error: redefinition of
>> 'struct _XConicalGradient'
>>
>> --Kurt
>
> Can you find out why libExt failed?
>
> Checking if "shmctl IPC_RMID allowes subsequent attaches" with dependencies
> x11, xext runs: DID NOT COMPILE
>
> Also please try with llvm.
I took a look at this a bit. Here’s what I found. The meson configure stage is
failing many checks that lead to an improper configuration and then results
in the the build failure above.
It looks to me like the root cause is a binutils-2.17 ld bug. Meson builds its
test programs with full paths to certain libraries and ld fails to link.
For example, here is the alarm test program:
#define alarm meson_disable_define_of_alarm
#include
#undef alarm
#ifdef __cplusplus
extern "C"
#endif
char alarm (void);
#if defined __stub_alarm || defined __stub___alarm
fail fail fail this function is not going to work
#endif
int main(void) {
return alarm ();
}
Its compiled and linked with the following command:
cc -I/usr/local/include -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include
-I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng16
-I/usr/local/include/lzo testfile.c -o output.exe -O2 -pipe -g
-D_FILE_OFFSET_BITS=64 -O0 -Wl,--start-group -lm /usr/local/lib/liblzo2.so.1.0
-lz /usr/local/lib/libpng.so.18.0 /usr/lib/libz.so.6.0
/usr/X11R6/lib/libfontconfig.so.13.0 /usr/X11R6/lib/libfreetype.so.30.0
/usr/X11R6/lib/libX11.so.17.1 /usr/X11R6/lib/libXext.so.13.0
/usr/X11R6/lib/libXrender.so.6.0 /usr/X11R6/lib/libxcb.so.4.1
/usr/X11R6/lib/libxcb-render.so.1.1 /usr/X11R6/lib/libxcb-shm.so.1.1
/usr/X11R6/lib/libpixman-1.so.40.0 -Wl,--end-group
And results in these linking errors:
/usr/X11R6/lib/libfontconfig.so.13.0: warning: sprintf() is often misused,
please use snprintf()
/usr/X11R6/lib/libfontconfig.so.13.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/X11R6/lib/libfontconfig.so.13.0: warning: strcat() is almost always
misused, please use strlcat()
/usr/bin/ld: warning: libX11.so.17.1, needed by /usr/X11R6/lib/libXext.so.13.0,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXau.so.10.0, needed by /usr/X11R6/lib/libxcb.so.4.1,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXdmcp.so.11.0, needed by /usr/X11R6/lib/libxcb.so.4.1,
not found (try using -rpath or -rpath-link)
/usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XdmcpWrap'
/usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XauGetBestAuthByAddr'
/usr/X11R6/lib/libxcb.so.4.1: undefined reference to `XauDisposeAuth’
Note the warning lines about not finding libs that are clearly in the list of
libs to link but using full paths instead of -llibX11 for example.
All of the failing configure tests are failing in the same way.
-Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/05 09:39:39 Modified files: sysutils/firmware/bwfm: Makefile distinfo sysutils/firmware/bwfm/pkg: PLIST Log message: Add support for Raspberry Pi Zero 2 W via brcm-supplemental and use Raspberry Pi 400 from brcm-supplemental as well. okay sthen@ patrick@
Re: clang 13 and __STDC_NO_ATOMICS__
On Nov 2, 2021, at 4:01 PM, Brad Smith wrote: > > On 11/2/2021 2:41 PM, Kurt Miller wrote: > >> On Nov 1, 2021, at 10:20 PM, Brad Smith wrote: >>> >>> On 10/28/2021 8:42 AM, Jeremie Courreges-Anglas wrote: >>>> On Thu, Oct 28 2021, Jeremie Courreges-Anglas wrote: >>>>> On Thu, Oct 28 2021, Christian Weisgerber wrote: >>>>>> I ran an amd64 bulk build with base clang updated to LLVM 13. >>>>>> >>>>>> There is substantial fallout. Java appears to be broken and there >>>>>> are numerous failures caused by clang 13 issuing new warnings and >>>>>> ports using -Werror. >>>>>> >>>>>> Failure logs: >>>>>> http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/ >>>>>> >>>>>> The final error may be misleading. For instance, devel/libdsm fails >>>>>> with a linker error "undefined reference to pthread_create", but >>>>>> the root cause is -Werror breaking a configure check. >>>>>> >>>>>> Below there's a list of affected ports. Several hundred more weren't >>>>>> built because they depend on something that failed. >>>>>> >>>>>> audio/cmus >>>>> jsg@ pointed out that this new clang defines __STDC_NO_ATOMICS__ >>>>> which is most likely wrong. This breaks at least cmus: >>>>> >>>>> >>>>> http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/audio/cmus.log >>>> Brad, are you sure that this change is 100% correct? >>>> https://github.com/llvm/llvm-project/commit/d8cd7806310c51af912a647a6ca46de62ff13214 >>>> >>>> Should we drop the __STDC_NO_ATOMICS__ define? >>> The atomics part was my misunderstanding and is wrong. I have reverted it >>> upstream and will >>> have it merged into 13. >> Thanks for fixing that. Can you explain why __STDC_NO_THREADS__ was >> retained? I’m >> assuming that’s disabling std::thread and related thread support which also >> seems wrong. > > This is for C11 not C++11. > > "If the macro constant __STDC_NO_THREADS__(C11) is defined by the compiler, > the > header and all of the names listed here are not provided." > > https://en.cppreference.com/w/c/thread > > OpenBSD currently does not implement C11 threads, unlike relatively new > FreeBSD, > NetBSD, Solaris, AIX, glibc, musl. > > https://svnweb.freebsd.org/base/head/lib/libstdthreads/threads.h > https://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/threads.h Thank you for the clarification. I see now I was confusing c++11 and c11. -Kurt
Re: clang 13 and __STDC_NO_ATOMICS__
On Nov 1, 2021, at 10:20 PM, Brad Smith wrote: > > > On 10/28/2021 8:42 AM, Jeremie Courreges-Anglas wrote: >> On Thu, Oct 28 2021, Jeremie Courreges-Anglas wrote: >>> On Thu, Oct 28 2021, Christian Weisgerber wrote: I ran an amd64 bulk build with base clang updated to LLVM 13. There is substantial fallout. Java appears to be broken and there are numerous failures caused by clang 13 issuing new warnings and ports using -Werror. Failure logs: http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/ The final error may be misleading. For instance, devel/libdsm fails with a linker error "undefined reference to pthread_create", but the root cause is -Werror breaking a configure check. Below there's a list of affected ports. Several hundred more weren't built because they depend on something that failed. audio/cmus >>> jsg@ pointed out that this new clang defines __STDC_NO_ATOMICS__ >>> which is most likely wrong. This breaks at least cmus: >>> >>> http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/audio/cmus.log >> Brad, are you sure that this change is 100% correct? >> https://github.com/llvm/llvm-project/commit/d8cd7806310c51af912a647a6ca46de62ff13214 >> >> Should we drop the __STDC_NO_ATOMICS__ define? > > The atomics part was my misunderstanding and is wrong. I have reverted it > upstream and will > have it merged into 13. Thanks for fixing that. Can you explain why __STDC_NO_THREADS__ was retained? I’m assuming that’s disabling std::thread and related thread support which also seems wrong. -Kurt
Re: UPDATE: sysutils/firmware/bwfm Rpi Zero 2 W & 400
> On Nov 2, 2021, at 2:34 PM, Klemens Nanni wrote:
>> DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
>>
>> {bsdkurt/brcm-supplemental/archive/}brcm-supplemental-${SUP_VER}.tar.gz:0 \
>> -
>> rpi-firmware-nonfree-{RPi-Distro/firmware-nonfree/archive/}83938f78ca2d5a0ffe0c223bb96d72ccc7b71ca5.tar.gz:0
>
> That backslash should go as well.
Good catch. I’ve fixed locally and will commit with it corrected.
Thanks,
-Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/11/02 10:03:06 Modified files: devel/jdk/11 : Makefile devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_hpp Added files: devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_assembler_aarch64_hpp Removed files: devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_c1_LIRAssembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_interp_masm_aarch64_cpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_trig_cpp patch-src_hotspot_cpu_aarch64_sharedRuntime_aarch64_cpp patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp patch-src_hotspot_cpu_aarch64_templateTable_aarch64_cpp Log message: Update the aarch64 type fixes to use a different approach that matches what newer versions of the jdk have implemented. Also fixes an issue where cvs removed a patch that should have been modified causing the aarch64 build to fail.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/31 16:32:52 Modified files: devel/jdk/17 : Makefile distinfo Removed files: devel/jdk/17/patches: patch-make_autoconf_flags-cflags_m4 patch-make_hotspot_lib_CompileJvm_gmk patch-make_modules_java_desktop_lib_Awt2dLibraries_gmk patch-src_hotspot_os_cpu_bsd_x86_os_bsd_x86_cpp Log message: Update to 17.0.1 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-17/?quarter=102021=allissues https://openjdk.java.net/groups/vulnerability/advisories/2021-10-19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/31 15:16:41 Modified files: devel/jdk/11 : Makefile distinfo devel/jdk/11/files: cacerts Added files: devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_aarch64_ad patch-src_hotspot_cpu_aarch64_assembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_c1_LIRAssembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_interp_masm_aarch64_cpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_cpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_hpp patch-src_hotspot_cpu_aarch64_macroAssembler_aarch64_trig_cpp patch-src_hotspot_cpu_aarch64_sharedRuntime_aarch64_cpp patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator_aarch64_cpp patch-src_hotspot_cpu_aarch64_templateTable_aarch64_cpp Removed files: devel/jdk/11/patches: patch-src_hotspot_cpu_aarch64_stubGenerator_aarch64_cpp patch-src_hotspot_share_oops_markOop_hpp Log message: Update to 11.0.13 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-11/?quarter=102021=allissues https://openjdk.java.net/groups/vulnerability/advisories/2021-10-19 * Update cacerts * Fix many aarch64 implicit conversion failures and other type related issues.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/31 14:55:28 Modified files: devel/jdk/1.8 : Makefile distinfo devel/jdk/1.8/files: cacerts devel/jdk/1.8/pkg: PLIST Removed files: devel/jdk/1.8/patches: patch-hotspot_make_bsd_makefiles_defs_make patch-hotspot_make_bsd_makefiles_jsig_make patch-hotspot_make_bsd_makefiles_saproc_make patch-hotspot_make_bsd_makefiles_vm_make patch-hotspot_src_share_vm_oops_markOop_hpp Log message: Update to 8u312 GA: * Contains many upstream bug fixes which can be found in the release notes here: https://foojay.io/java-8/?tab=allissues=openjdk8u312=102021 https://openjdk.java.net/groups/vulnerability/advisories/2021-10-19 * Update cacerts
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/30 16:48:11 Modified files: devel/jdk/1.8 : Makefile devel/jdk/11 : Makefile devel/jdk/17 : Makefile devel/jdk/17/patches: patch-make_hotspot_lib_CompileJvm_gmk Added files: devel/jdk/1.8/patches: patch-hotspot_src_share_vm_oops_markOop_hpp devel/jdk/11/patches: patch-src_hotspot_share_oops_markOop_hpp Log message: Fix build with llvm 13. okay naddy@
Re: aarch64 fix for java/tanukiwrapper
On Sat, 2021-10-30 at 15:33 +0200, Peter Hessler wrote:
> The build system seems to expect aarch64 to be arm-64, and treats armhf
> as 32bit. Update the Makefile(s) and patch to reflect this.
>
> No REVISION because it doesn't build on aarch64, and this shouldn't
> affect any other arch.
>
> Build error:
> http://build-failures.rhaalovely.net/aarch64/2021-10-22/java/tanukiwrapper.log
>
> OK?
Looking at the release notes:
https://wrapper.tanukisoftware.com/doc/english/release-notes.html#3.5.46
armhf was renamed to just arm for aarch64, so this looks correct to me.
okay kurt@
>
>
> Index: Makefile
> ===
> RCS file: /cvs/openbsd/ports/java/tanukiwrapper/Makefile,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 Makefile
> --- Makefile 16 Oct 2021 08:07:39 - 1.23
> +++ Makefile 30 Oct 2021 13:28:32 -
> @@ -31,7 +31,7 @@ MAKE_ARCH=x86-32
> .elif ${MACHINE_ARCH} == "amd64"
> MAKE_ARCH=x86-64
> .elif ${MACHINE_ARCH} == "aarch64"
> -MAKE_ARCH=armhf-64
> +MAKE_ARCH=arm-64
> .elif ${MACHINE_ARCH} == "sparc64"
> MAKE_ARCH=sparc-64
> .endif
> Index: files/Makefile-openbsd-arm-64.gmake
> ===
> RCS file: files/Makefile-openbsd-arm-64.gmake
> diff -N files/Makefile-openbsd-arm-64.gmake
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/Makefile-openbsd-arm-64.gmake 21 May 2021 11:51:08 -
> @@ -0,0 +1,42 @@
> +# Copyright (c) 1999, 2013 Tanuki Software, Ltd.
> +# http://www.tanukisoftware.com
> +# All rights reserved.
> +#
> +# This software is the proprietary information of Tanuki Software.
> +# You shall use it only in accordance with the terms of the
> +# license agreement you entered into with Tanuki Software.
> +# http://wrapper.tanukisoftware.com/doc/english/licenseOverview.html
> +
> +CC = ${CC} -Wall -fPIC -pedantic -DOPENBSD -DJSW64 -I${LOCALBASE}/include
> -L${LOCALBASE}/lib -liconv -DUNICODE
> -D_UNICODE
> +
> +INCLUDE=$(JAVA_HOME)/include
> +
> +CFLAGS = ${CFLAGS} -I$(INCLUDE) -I$(INCLUDE)/openbsd
> +
> +wrapper_SOURCE = wrapper.c wrapperinfo.c wrappereventloop.c wrapper_unix.c
> property.c logger.c logger_file.c
> wrapper_file.c wrapper_i18n.c wrapper_hashmap.c wrapper_ulimit.c
> wrapper_encoding.c wrapper_jvminfo.c
> +
> +libwrapper_so_OBJECTS = wrapper_i18n.o wrapperjni_unix.o wrapperinfo.o
> wrapperjni.o loggerjni.o
> +
> +BIN = ../../bin
> +LIB = ../../lib
> +
> +all: init wrapper libwrapper.so
> +
> +clean:
> + rm -f *.o
> +
> +cleanall: clean
> + rm -rf *~ .deps
> + rm -f $(BIN)/wrapper $(LIB)/libwrapper.so
> +
> +init:
> + if test ! -d .deps; then mkdir .deps; fi
> +
> +wrapper: $(wrapper_SOURCE)
> + $(CC) $(wrapper_SOURCE) -lm -rdynamic -lc -pthread -o $(BIN)/wrapper
> +
> +libwrapper.so: $(libwrapper_so_OBJECTS)
> + $(CC) -shared -rdynamic -lc -pthread $(libwrapper_so_OBJECTS) -o
> $(LIB)/libwrapper.so
> +
> +#%.o: %.c
> +#$(COMPILE) -c $(DEFS) $<
> Index: files/Makefile-openbsd-armhf-64.gmake
> ===
> RCS file: files/Makefile-openbsd-armhf-64.gmake
> diff -N files/Makefile-openbsd-armhf-64.gmake
> --- files/Makefile-openbsd-armhf-64.gmake 21 May 2021 11:51:08 -
> 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,42 +0,0 @@
> -# Copyright (c) 1999, 2013 Tanuki Software, Ltd.
> -# http://www.tanukisoftware.com
> -# All rights reserved.
> -#
> -# This software is the proprietary information of Tanuki Software.
> -# You shall use it only in accordance with the terms of the
> -# license agreement you entered into with Tanuki Software.
> -# http://wrapper.tanukisoftware.com/doc/english/licenseOverview.html
> -
> -CC = ${CC} -Wall -fPIC -pedantic -DOPENBSD -DJSW64 -I${LOCALBASE}/include
> -L${LOCALBASE}/lib -liconv -DUNICODE
> -D_UNICODE
> -
> -INCLUDE=$(JAVA_HOME)/include
> -
> -CFLAGS = ${CFLAGS} -I$(INCLUDE) -I$(INCLUDE)/openbsd
> -
> -wrapper_SOURCE = wrapper.c wrapperinfo.c wrappereventloop.c wrapper_unix.c
> property.c logger.c logger_file.c
> wrapper_file.c wrapper_i18n.c wrapper_hashmap.c wrapper_ulimit.c
> wrapper_encoding.c wrapper_jvminfo.c
> -
> -libwrapper_so_OBJECTS = wrapper_i18n.o wrapperjni_unix.o wrapperinfo.o
> wrapperjni.o loggerjni.o
> -
> -BIN = ../../bin
> -LIB = ../../lib
> -
> -all: init wrapper libwrapper.so
> -
> -clean:
> - rm -f *.o
> -
> -cleanall: clean
> - rm -rf *~ .deps
> - rm -f $(BIN)/wrapper $(LIB)/libwrapper.so
> -
> -init:
> - if test ! -d .deps; then mkdir .deps; fi
> -
> -wrapper: $(wrapper_SOURCE)
> - $(CC) $(wrapper_SOURCE) -lm -rdynamic -lc -pthread -o $(BIN)/wrapper
> -
> -libwrapper.so: $(libwrapper_so_OBJECTS)
> - $(CC) -shared -rdynamic -lc -pthread $(libwrapper_so_OBJECTS) -o
> $(LIB)/libwrapper.so
> -
> -#%.o: %.c
> -#$(COMPILE) -c $(DEFS) $<
> Index: patches/patch-build_xml
>
