Re: OpenJDK ports and 13-CURRENT
From: Yasuhiro KIMURA Subject: Re: OpenJDK ports and 13-CURRENT Date: Sun, 11 Oct 2020 08:35:39 +0900 (JST) > From: Dimitry Andric > Subject: Re: OpenJDK ports and 13-CURRENT > Date: Sun, 11 Oct 2020 00:57:33 +0200 > >> Can you try the attached patch? I haven't yet looked at openjdk 13 and >> up, but I assume they will need at least the XSynchronize fix, and maybe >> the above ones, if the upstream branches were made after 2020-02-05. > > I tried your patch but it fails at patch phase as following. I modified your patch as following and now build of java/openjdk12 succeeeds on 13-CURRENT amd64 r366578. >From 5fb14c6b20c000f57ad975d79aed0072f142ec80 Mon Sep 17 00:00:00 2001 From: Yasuhiro KIMURA Date: Sun, 11 Oct 2020 10:28:47 +0900 Subject: [PATCH] java/openjdk12: Fix build with -fno-common (Clang 11/GCC 10) Fix build with -fno-common (Clang 11/GCC 10) --- java/openjdk12/files/patch-changeset-57932| 27 +++ java/openjdk12/files/patch-changeset-57994| 26 ++ ..._unix_classes_sun_awt_X11_XlibWrapper.java | 11 ...nix_native_libawt__xawt_xawt_XlibWrapper.c | 15 +++ 4 files changed, 79 insertions(+) create mode 100644 java/openjdk12/files/patch-changeset-57932 create mode 100644 java/openjdk12/files/patch-changeset-57994 create mode 100644 java/openjdk12/files/patch-src_java.desktop_unix_classes_sun_awt_X11_XlibWrapper.java create mode 100644 java/openjdk12/files/patch-src_java.desktop_unix_native_libawt__xawt_xawt_XlibWrapper.c diff --git a/java/openjdk12/files/patch-changeset-57932 b/java/openjdk12/files/patch-changeset-57932 new file mode 100644 index ..24b929d5ac08 --- /dev/null +++ b/java/openjdk12/files/patch-changeset-57932 @@ -0,0 +1,27 @@ +changeset: 57932:9e54ea7d9cd9 +user:qpzhang +date:Wed Feb 05 20:31:09 2020 +0800 +summary: 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 + +--- src/java.security.jgss/share/native/libj2gss/NativeFunc.c.orig 2020-04-17 22:35:42 UTC src/java.security.jgss/share/native/libj2gss/NativeFunc.c +@@ -27,6 +27,9 @@ + #include + #include "NativeFunc.h" + ++/* global GSS function table */ ++GSS_FUNCTION_TABLE_PTR ftab; ++ + /* standard GSS method names (ordering is from mapfile) */ + static const char RELEASE_NAME[]= "gss_release_name"; + static const char IMPORT_NAME[] = "gss_import_name"; +--- src/java.security.jgss/share/native/libj2gss/NativeFunc.h.orig 2020-04-17 22:35:42 UTC src/java.security.jgss/share/native/libj2gss/NativeFunc.h +@@ -277,6 +277,6 @@ typedef struct GSS_FUNCTION_TABLE { + typedef GSS_FUNCTION_TABLE *GSS_FUNCTION_TABLE_PTR; + + /* global GSS function table */ +-GSS_FUNCTION_TABLE_PTR ftab; ++extern GSS_FUNCTION_TABLE_PTR ftab; + + #endif diff --git a/java/openjdk12/files/patch-changeset-57994 b/java/openjdk12/files/patch-changeset-57994 new file mode 100644 index ..ac5ef8190d89 --- /dev/null +++ b/java/openjdk12/files/patch-changeset-57994 @@ -0,0 +1,26 @@ +changeset: 57994:6925fca95959 +user:qpzhang +date:Tue Feb 04 21:27:10 2020 +0800 +summary: 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 + +--- src/java.base/unix/native/libjava/childproc.c.orig 2020-04-17 22:35:42 UTC src/java.base/unix/native/libjava/childproc.c +@@ -33,6 +33,7 @@ + + #include "childproc.h" + ++const char * const *parentPathv; + + ssize_t + restartableWrite(int fd, const void *buf, size_t count) +--- src/java.base/unix/native/libjava/childproc.h.orig 2020-04-17 22:35:42 UTC src/java.base/unix/native/libjava/childproc.h +@@ -118,7 +118,7 @@ typedef struct _SpawnInfo { + * The cached and split version of the JDK's effective PATH. + * (We don't support putenv("PATH=...") in native code) + */ +-const char * const *parentPathv; ++extern const char * const *parentPathv; + + ssize_t restartableWrite(int fd, const void *buf, size_t count); + int restartableDup2(int fd_from, int fd_to); diff --git a/java/openjdk12/files/patch-src_java.desktop_unix_classes_sun_awt_X11_XlibWrapper.java b/java/openjdk12/files/patch-src_java.desktop_unix_classes_sun_awt_X11_XlibWrapper.java new file mode 100644 index ..4f3913a95410 --- /dev/null +++ b/java/openjdk12/files/patch-src_java.desktop_unix_classes_sun_awt_X11_XlibWrapper.java @@ -0,0 +1,11 @@ +--- src/java.desktop/unix/classes/sun/awt/X11/XlibWrapper.java.orig 2020-04-17 22:35:42 UTC src/java.desktop/unix/classes/sun/awt/X11/XlibWrapper.java +@@ -529,7 +529,7 @@ static native String XSetLocaleModifiers(String modifi + display Specifies the connection to the X server. + onoff Specifies a Boolean value that indicates whether to enable or disable synchronization. + */ +-static native int XSynchronize(long display, boolean onoff); ++static native long XSynchronize(long display, boolean onoff); +
Re: OpenJDK ports and 13-CURRENT
From: Dimitry Andric Subject: Re: OpenJDK ports and 13-CURRENT Date: Sun, 11 Oct 2020 00:57:33 +0200 > Can you try the attached patch? I haven't yet looked at openjdk 13 and > up, but I assume they will need at least the XSynchronize fix, and maybe > the above ones, if the upstream branches were made after 2020-02-05. I tried your patch but it fails at patch phase as following. yasu@rolling-vm-freebsd1[1326]% make PORTSDIR=/usr0/freebsd/ports/git check-plist ===> License GPLv2 accepted by the user ===> openjdk12-12.0.2+10.4_1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by openjdk12-12.0.2+10.4_1 for building ===> Extracting for openjdk12-12.0.2+10.4_1 => SHA256 Checksum OK for battleblow-openjdk-jdk12u-jdk-12.0.2+10-4_GH0.tar.gz. ===> Patching for openjdk12-12.0.2+10.4_1 ===> Applying FreeBSD patches for openjdk12-12.0.2+10.4_1 from /usr0/freebsd/ports/git/java/openjdk12/files 2 out of 2 hunks failed--saving rejects to src/java.security.jgss/share/native/libj2gss/NativeFunc.c.rej 2 out of 2 hunks failed--saving rejects to src/java.security.jgss/share/native/libj2gss/NativeFunc.h.rej ===> FAILED Applying FreeBSD patch-changeset-57932 ===> Cleanly applied FreeBSD patch(es) patch-10-af5c725b ===> FAILED to apply cleanly FreeBSD patch(es) patch-changeset-57932 *** Error code 1 Stop. make: stopped in /usr0/freebsd/ports/git/java/openjdk12 yasu@rolling-vm-freebsd1[1327]% --- Yasuhiro KIMURA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: OpenJDK ports and 13-CURRENT
On 10 Oct 2020, at 21:49, Shawn Webb wrote: > > On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote: >> On 10 Oct 2020, at 21:23, Shawn Webb wrote: ... >>> Log of the HardenedBSD 13-CURRENT/amd64 package >>> build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log ... >> Ah, that is -fno-common fallout, strange that there is no build breakage >> reported in the FreeBSD ports build cluster? Ok, the -fno-common problems were already fixed by upstream in: https://hg.openjdk.java.net/jdk/jdk/rev/6925fca95959 https://hg.openjdk.java.net/jdk/jdk/rev/9e54ea7d9cd9 but these apparently weren't ported back to openjdk 12. The port also needed a fix for the awt wrapper for XSynchronize using the wrong return type, e.g. it should use jlong instead of jint. This should be upstreamed to the OpenJDK folks, as it is really a bug in the JDK itself. Can you try the attached patch? I haven't yet looked at openjdk 13 and up, but I assume they will need at least the XSynchronize fix, and maybe the above ones, if the upstream branches were made after 2020-02-05. -Dimitry java__openjdk12-fix-clang11-build-1.diff Description: Binary data signature.asc Description: Message signed with OpenPGP
Re: FreeBSD Port: telegram-desktop-2.3.2 videocalls
Okay, it seems like that there's a DCHECK related to threading. However, if I disable the DCHECKs, video call seems to work. It's not ideal, as typically these should not fail. But for now, I'll just send a patch to disable it. Would you please file a problem report so we can follow up there? On Thu, Oct 1, 2020 at 11:48 AM Alex V. Petrov wrote: > No. Audio calls working perfectly. Problems only with videocalls. > > On Thu, Oct 01, 2020 at 06:18:55PM +0300, Michael Zhilin wrote: > >Hi, > >I supposed that neither audio or video calls work in FreeBSD Telegram > >client. > >Time to fix it? > >Thanks, > > Michael > >On Thu, Oct 1, 2020 at 6:10 PM Alex V. Petrov <[1] > alexvpet...@gmail.com> > >wrote: > > > > Anyone have working videocalls in the telegram-desktop? > > For me it don't work. > > Any attempt to configure the camera will close the program with: > > > > (audio_device_buffer.cc:118): StartRecording > > (audio_device_impl.cc:826): output: -1 > > (device_info_linux.cc:45): NumberOfDevices > > (device_info_linux.cc:70): GetDeviceName > > (device_info_linux.cc:70): GetDeviceName > > (device_info_linux.cc:70): GetDeviceName > > (device_info_linux.cc:143): CreateCapabilityMap called for device > > usb-/dev/usb-/dev/usb > > (device_info_linux.cc:274): CreateCapabilityMap 8 > > (device_info_linux.cc:195): CreateCapabilityMap 8 > > (video_capture_linux.cc:153): Video Capture enumerats supported > image > > formats: > > (video_capture_linux.cc:155): { pixelformat = JPEG, description = > > 'dddec81c' } > > (video_capture_linux.cc:171): We prefer format JPEG > > (video_capture_linux.cc:195): error in VIDIOC_S_FMT, errno = 16 > > (VideoCameraCapturer.cpp:78): Failed to start VideoCameraCapturer > > 'usb-/dev/usb-/dev/usb'. > > (device_info_linux.cc:70): GetDeviceName > > (video_capture_linux.cc:153): Video Capture enumerats supported > image > > formats: > > (video_capture_linux.cc:155): { pixelformat = JPEG, description = > > 'dddec81c' } > > (video_capture_linux.cc:171): We prefer format JPEG > > (video_capture_linux.cc:195): error in VIDIOC_S_FMT, errno = 16 > > (VideoCameraCapturer.cpp:78): Failed to start VideoCameraCapturer > > 'usb-/dev/usb-/dev/usb'. > > (device_info_linux.cc:70): GetDeviceName > > (video_capture_linux.cc:153): Video Capture enumerats supported > image > > formats: > > (video_capture_linux.cc:155): { pixelformat = JPEG, description = > > 'dddec81c' } > > (video_capture_linux.cc:171): We prefer format JPEG > > (video_capture_linux.cc:195): error in VIDIOC_S_FMT, errno = 16 > > (VideoCameraCapturer.cpp:78): Failed to start VideoCameraCapturer > > 'usb-/dev/usb-/dev/usb'. > > (device_info_linux.cc:70): GetDeviceName > > (video_capture_linux.cc:153): Video Capture enumerats supported > image > > formats: > > (video_capture_linux.cc:155): { pixelformat = JPEG, description = > > 'dddec81c' } > > (video_capture_linux.cc:171): We prefer format JPEG > > (video_capture_linux.cc:195): error in VIDIOC_S_FMT, errno = 16 > > (VideoCameraCapturer.cpp:78): Failed to start VideoCameraCapturer > > 'usb-/dev/usb-/dev/usb'. > > (thread.cc:668): Message took 86ms to dispatch. Posted from: > > ThreadLocalObject@ > /usr/ports/net-im/telegram-desktop/work/tdesktop-2.3.2-full/Telegram/ThirdParty/tgcalls/tgcalls/ThreadLocalObject.h:22 > > > > # > > # Fatal error in: ../../src/rtc_base/critical_section.cc, line 123 > > # last system error: 0 > > # Check failed: CurrentThreadIsOwner() > > > > -- > > - > > Alex. > > ___ > > [2]freebsd-ports@freebsd.org mailing list > > [3]https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to > > "[4]freebsd-ports-unsubscr...@freebsd.org" > > > > References > > > >Visible links > >1. mailto:alexvpet...@gmail.com > >2. mailto:freebsd-ports@freebsd.org > >3. https://lists.freebsd.org/mailman/listinfo/freebsd-ports > >4. mailto:freebsd-ports-unsubscr...@freebsd.org > -- Cheers, Henry ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: OpenJDK ports and 13-CURRENT
Le sam. 10 oct. 20 à 21:49:26 +0200, Shawn Webb écrivait : > > Ah, that is -fno-common fallout, strange that there is no build breakage > > reported in the FreeBSD ports build cluster? > > > > From gcc 10 and clang 11 onwards, -fno-common is the default (this is > > really a historical mistake, -fcommon should never have been default). > > > > It can result in link errors, if duplicate symbols exist in object > > files. There is a suprising amount of software that makes this very > > basic mistake! > > > > The quick way to work around these errors is to set -fcommon in CFLAGS, > > which will basically fudge around the actual issue. The better way is to > > get rid of the duplicated symbols. This is usually easy, except that > > Java ports tend to take ages to build. :) I'll submit a patch when my > > machine's finished crunching through it. > > Yup. Another victim: print/tex-luatex: > > https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/commit/229b7663bc82ff7e471dc1e19662f68d4226984a There is a meta-PR for that: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248756 Regards. -- Th. Thomas. signature.asc Description: PGP signature
Re: OpenJDK ports and 13-CURRENT
On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote: > On 10 Oct 2020, at 21:23, Shawn Webb wrote: > > > > On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote: > >> On 10 Oct 2020, at 21:03, Shawn Webb wrote: > >>> It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and > >>> above ports. Is anyone tracking this breakage? > >> > >> Define "break". :) I can't find any PR, so I don't think so. The latest > >> builds on the ports cluster seem to have succeeded, but even though the > >> ports builder says "head-amd64-default-job", it appears to compile with > >> clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't > >> know. > > > > Log of the HardenedBSD 13-CURRENT/amd64 package > > build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log > > > > HardenedBSD has switched to a full llvm compiler toolchain. I wonder > > if that's the culprit? Using llvm-ar, llvm-nm, et al. > > > > Googling for the duplicate symbol error brought me this result: > > https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html > > Ah, that is -fno-common fallout, strange that there is no build breakage > reported in the FreeBSD ports build cluster? > > From gcc 10 and clang 11 onwards, -fno-common is the default (this is > really a historical mistake, -fcommon should never have been default). > > It can result in link errors, if duplicate symbols exist in object > files. There is a suprising amount of software that makes this very > basic mistake! > > The quick way to work around these errors is to set -fcommon in CFLAGS, > which will basically fudge around the actual issue. The better way is to > get rid of the duplicated symbols. This is usually easy, except that > Java ports tend to take ages to build. :) I'll submit a patch when my > machine's finished crunching through it. Yup. Another victim: print/tex-luatex: https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/commit/229b7663bc82ff7e471dc1e19662f68d4226984a -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: OpenJDK ports and 13-CURRENT
On 10 Oct 2020, at 21:23, Shawn Webb wrote: > > On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote: >> On 10 Oct 2020, at 21:03, Shawn Webb wrote: >>> It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and >>> above ports. Is anyone tracking this breakage? >> >> Define "break". :) I can't find any PR, so I don't think so. The latest >> builds on the ports cluster seem to have succeeded, but even though the >> ports builder says "head-amd64-default-job", it appears to compile with >> clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't >> know. > > Log of the HardenedBSD 13-CURRENT/amd64 package > build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log > > HardenedBSD has switched to a full llvm compiler toolchain. I wonder > if that's the culprit? Using llvm-ar, llvm-nm, et al. > > Googling for the duplicate symbol error brought me this result: > https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html Ah, that is -fno-common fallout, strange that there is no build breakage reported in the FreeBSD ports build cluster? From gcc 10 and clang 11 onwards, -fno-common is the default (this is really a historical mistake, -fcommon should never have been default). It can result in link errors, if duplicate symbols exist in object files. There is a suprising amount of software that makes this very basic mistake! The quick way to work around these errors is to set -fcommon in CFLAGS, which will basically fudge around the actual issue. The better way is to get rid of the duplicated symbols. This is usually easy, except that Java ports tend to take ages to build. :) I'll submit a patch when my machine's finished crunching through it. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: OpenJDK ports and 13-CURRENT
On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote: > On 10 Oct 2020, at 21:03, Shawn Webb wrote: > > It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and > > above ports. Is anyone tracking this breakage? > > Define "break". :) I can't find any PR, so I don't think so. The latest > builds on the ports cluster seem to have succeeded, but even though the > ports builder says "head-amd64-default-job", it appears to compile with > clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't > know. Log of the HardenedBSD 13-CURRENT/amd64 package build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log HardenedBSD has switched to a full llvm compiler toolchain. I wonder if that's the culprit? Using llvm-ar, llvm-nm, et al. Googling for the duplicate symbol error brought me this result: https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: OpenJDK ports and 13-CURRENT
On 10 Oct 2020, at 21:03, Shawn Webb wrote: > It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and > above ports. Is anyone tracking this breakage? Define "break". :) I can't find any PR, so I don't think so. The latest builds on the ports cluster seem to have succeeded, but even though the ports builder says "head-amd64-default-job", it appears to compile with clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't know. -Dimitry signature.asc Description: Message signed with OpenPGP
OpenJDK ports and 13-CURRENT
Hey all, It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and above ports. Is anyone tracking this breakage? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: When to set / keep MAKE_JOBS_UNSAFE?
Kurt Jaeger (Oct 10, 2020): > > In its Makefile MAKE_JOBS_UNSAFE is set and I'm trying to figure out if > > it's acutally needed or not. > > If you build it on a box with more CPUs cores, will it fail or not ? > > What number of CPUs cores did you try ? I built it successfully on FreeBSD freebsd.current 13.0-CURRENT FreeBSD 13.0-CURRENT #0 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 hw.machine: amd64 hw.ncpu: 12 > I've just tried it without MAKE_JOBS_UNSAFE on a 32 and it built > fine. So I guess you can remove it. This would also be my guess. Best, Moritz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: When to set / keep MAKE_JOBS_UNSAFE?
Hi! > In its Makefile MAKE_JOBS_UNSAFE is set and I'm trying to figure out if > it's acutally needed or not. If you build it on a box with more CPUs cores, will it fail or not ? What number of CPUs cores did you try ? I've just tried it without MAKE_JOBS_UNSAFE on a 32 and it built fine. So I guess you can remove it. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
When to set / keep MAKE_JOBS_UNSAFE?
Hi, I recently took over maintainership of devel/gindent, and I'm in the process of cleaning it up. In its Makefile MAKE_JOBS_UNSAFE is set and I'm trying to figure out if it's acutally needed or not. Subversion's log has the following entry: r244490 | pav | 2009-11-20 00:41:55 +0100 (Fri, 20 Nov 2009) | 4 lines - Mark MAKE_JOBS_UNSAFE Reported by:pointyhat This commit message is undoubtedly correct, but alas, not very convincing. And unfortunately, I couldn't find the report by pointyhat. If I remove MAKE_JOBS_UNSAFE, the port seems to build without any problems at all. I also couldn't find any restrictions specified in the source of GNU indent. However, from this we cannot deduce that it's safe to build the port in parallel. How do porters usually deal with such a situation? Best, Moritz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"