Re: OpenJDK ports and 13-CURRENT

2020-10-17 Thread Dimitry Andric
On 10 Oct 2020, at 21:49, Shawn Webb  wrote:
> 
> On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote:
...
>> 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

I looked into this one finally, and it's not really an issue with any
recent clang import, as the PR is from 2018-12-20:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234221

The cause is a mixing of libstdc++ and libc++, which should not be done,
as it will almost always lead to unexpected linking errors.

The following diff fixes that:

Index: Makefile
===
--- Makefile(revision 552400)
+++ Makefile(working copy)
@@ -74,6 +74,8 @@ CONFIGURE_ARGS+=--with-system-$L \
--with-$L-include=${LOCALBASE}/include \
--with-$L-libdir=${LOCALBASE}/lib
 .endfor
+CONFIGURE_ARGS+=CC="${CC}" \
+   CXX="${CXX}"
 CPPFLAGS+= -I${LOCALBASE}/include
 MAKE_JOBS_UNSAFE=  yes
 TEX_FORMATS=   luatex


Note that the port's Makefile already has -fcommon added, to work
around duplicated symbols. Since the copy of texlive is ancient, it is
probably not worth the time to fix the actual issues.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: OpenJDK ports and 13-CURRENT

2020-10-11 Thread Dimitry Andric
On 11 Oct 2020, at 08:57, Yasuhiro KIMURA  wrote:
> 
> From: Yasuhiro KIMURA 
> Subject: Re: OpenJDK ports and 13-CURRENT
> Date: Sun, 11 Oct 2020 08:35:39 +0900 (JST)
> 
>>> 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.
> 
> Sorry, I made a mistake. Your patch just works fine on 13-CURRENT
> amd64 r366578.

I submitted https://bugs.freebsd.org/250270, with patches for openjdk 12
through 15, and added a reference to https://bugs.freebsd.org/248756
which is the meta-bug for -fno-common issues.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: OpenJDK ports and 13-CURRENT

2020-10-11 Thread Yasuhiro KIMURA
From: Yasuhiro KIMURA 
Subject: Re: OpenJDK ports and 13-CURRENT
Date: Sun, 11 Oct 2020 08:35:39 +0900 (JST)

>> 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.

Sorry, I made a mistake. Your patch just works fine on 13-CURRENT
amd64 r366578.

---
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

2020-10-10 Thread Yasuhiro KIMURA
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

Re: OpenJDK ports and 13-CURRENT

2020-10-10 Thread Yasuhiro KIMURA
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

2020-10-10 Thread Dimitry Andric
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: OpenJDK ports and 13-CURRENT

2020-10-10 Thread Thierry Thomas
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

2020-10-10 Thread Shawn Webb
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

2020-10-10 Thread Dimitry Andric
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

2020-10-10 Thread Shawn Webb
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

2020-10-10 Thread Dimitry Andric
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

2020-10-10 Thread Shawn Webb
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