OpenJDK ports and 13-CURRENT

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenJDK ports and 13-CURRENT

Shawn Webb-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Dimitry Andric-4
On 10 Oct 2020, at 21:03, Shawn Webb <[hidden email]> 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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Shawn Webb-3
On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote:
> On 10 Oct 2020, at 21:03, Shawn Webb <[hidden email]> 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@.../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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Dimitry Andric-4
On 10 Oct 2020, at 21:23, Shawn Webb <[hidden email]> wrote:

>
> On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote:
>> On 10 Oct 2020, at 21:03, Shawn Webb <[hidden email]> 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@.../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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Shawn Webb-3
On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote:

> On 10 Oct 2020, at 21:23, Shawn Webb <[hidden email]> wrote:
> >
> > On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote:
> >> On 10 Oct 2020, at 21:03, Shawn Webb <[hidden email]> 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@.../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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Thierry Thomas
Le sam. 10 oct. 20 à 21:49:26 +0200, Shawn Webb <[hidden email]>
 é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 (949 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Dimitry Andric-4
In reply to this post by Shawn Webb-3
On 10 Oct 2020, at 21:49, Shawn Webb <[hidden email]> wrote:
>
> On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote:
>> On 10 Oct 2020, at 21:23, Shawn Webb <[hidden email]> 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 (7K) Download Attachment
signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Yasuhiro KIMURA
From: Dimitry Andric <[hidden email]>
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Yasuhiro KIMURA
From: Yasuhiro KIMURA <[hidden email]>
Subject: Re: OpenJDK ports and 13-CURRENT
Date: Sun, 11 Oct 2020 08:35:39 +0900 (JST)

> From: Dimitry Andric <[hidden email]>
> 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 <[hidden email]>
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 000000000000..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 <stdlib.h>
+ #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 000000000000..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 000000000000..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);
+
+     /**
+      * Extracts an X event that can be processed in a secondary loop.
diff --git a/java/openjdk12/files/patch-src_java.desktop_unix_native_libawt__xawt_xawt_XlibWrapper.c b/java/openjdk12/files/patch-src_java.desktop_unix_native_libawt__xawt_xawt_XlibWrapper.c
new file mode 100644
index 000000000000..b4d602993ab9
--- /dev/null
+++ b/java/openjdk12/files/patch-src_java.desktop_unix_native_libawt__xawt_xawt_XlibWrapper.c
@@ -0,0 +1,15 @@
+--- src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c.orig 2020-04-17 22:35:42 UTC
++++ src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
+@@ -2180,10 +2180,10 @@ Java_sun_awt_X11_XlibWrapper_copyLongArray(JNIEnv *env
+     }
+ }
+
+-JNIEXPORT jint JNICALL
++JNIEXPORT jlong JNICALL
+ Java_sun_awt_X11_XlibWrapper_XSynchronize(JNIEnv *env, jclass clazz, jlong display, jboolean onoff)
+ {
+-    return (jint) XSynchronize((Display*)jlong_to_ptr(display), (onoff == JNI_TRUE ? True : False));
++    return ptr_to_jlong(XSynchronize((Display*)jlong_to_ptr(display), (onoff == JNI_TRUE ? True : False)));
+ }
+
+ JNIEXPORT jboolean JNICALL
--
2.28.0

---
Yasuhiro KIMURA
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Yasuhiro KIMURA
In reply to this post by Yasuhiro KIMURA
From: Yasuhiro KIMURA <[hidden email]>
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Dimitry Andric-4
On 11 Oct 2020, at 08:57, Yasuhiro KIMURA <[hidden email]> wrote:

>
> From: Yasuhiro KIMURA <[hidden email]>
> 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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK ports and 13-CURRENT

Dimitry Andric-4
In reply to this post by Shawn Webb-3
On 10 Oct 2020, at 21:49, Shawn Webb <[hidden email]> 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 (230 bytes) Download Attachment