Changelog: https://github.com/WebKit/WebKit/blob/webkitgtk-2.46.5/Source/WebKit/gtk/NEWS
Now consolidated into one port with flavours since the codebase is
the same, just linked with different libraries resulting in different
SONAMEs and APIs. SONAMEs/flavours:
* GTK3 + libsoup = libwebkit2gtk-4.0 (40)
* GTK3 + libsoup3 = libwebkit2gtk-4.1 (41)
* GTK4 + libsoup3 = libwebkitgtk-6.0 (60)
Despite upstream's recommendation to use clang for better skia
optimisation, this port now USE_GCC due to extensive std::pair copy
constructor use that is not trivial to continue patching to stay
working with our libc++ version 1 ABI. See review D35327 for some
details.
Reported by: eduardo
PR: 275914
Differential Revision: https://reviews.freebsd.org/D45878
Copy patch from java/openjdk22 to fix:
Error: dl failure on line 564
Error: failed /wrkdirs/usr/ports/java/openjdk23/work/jdk23u-jdk-23.0.1-11-1/build/bsd-ppc64-server-release/jdk/lib/server/libjvm.so, because /wrkdirs/usr/ports/java/openjdk23/work/jdk23u-jdk-23.0.1-11-1/build/bsd-ppc64-server-release/jdk/lib/server/libjvm.so: Undefined symbol "_ZN2os27current_stack_base_and_sizeEPPhPm"
OpenJDK installation inform that fdescfs(5) and procfs(5) should be
mounted when using OpenJDK.
After doing some test and some traces, it seems that this should be
no so usefull, some applications will require it, but most of java
applications doesn't seems to suffer to work or performance when
such pseudo FS is not mounted.
So this change request permit to let local administrator to decide if
it is really needed or not.
Sponsored by: Entersekt (previously Modirum MDpay)
Sponsored by: Klara Inc.
Approved by: 0mp (mentor)
PR: 283364
USES=java:ant does not imply USES=java:run so we need to add the run arg
seperately when we are using USES=java:ant. Not all ports require the
the argument so it is better to address the ports individually instead
of handling it automatically by implying run for ant.
Thanks to vvd for carefully going through this.
Reported by: vvd
Approved by: portmgr (blanket)
This was marked for deletion with the advise to use bouncycastle15. So
instead bouncycastle15 has been moved to boucycastle.
Approved by: portmgr (blanket)
The following features have been added or changed:
- Instead of USE_JAVA use USES=java. This defaults to
USES=java:build,run if NO_BUILD is undefined. Else it defaults to
USES=java:run
- Instead of USE_ANT=yes use USES=java:ant which also implies
USES=java:build
- Instead of JAVA_BUILD=yes use USES=java:build. Does not imply run or
extract
- Instead of JAVA_EXTRACT=yes use USES=java:extract does not imply
build or run
- Instead of JAVA_RUN=yes use USES=java:run does not imply extract or
build
- Instead of USE_JAVA=<version> use USES=java and JAVA_VERSION=<version>
Approved by: mat (portmgr), glewis
Differential Revision: https://reviews.freebsd.org/D48201
On FreeBSD 14 and 15 the i386 build fails with a segfault.
Reviewed by: bofh, jrm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48252
- Java InfoBus is an outdated API and is no longer actively developed or
maintained
- Modern Java development practices and frameworks have replaced the
functionality provided by InfoBus
- No known consumers or upstream support exist for this library
- Upstream distfiles are no longer available as Sun stopped developing
this long before their merger with Oracle
- Set EXPIRATION_DATE 2025-01-24
Approved by: portmgr (blanket)
install -s -m 0644 /wrkdirs/usr/ports/java/intellij-ultimate/work/jna/com/sun/jna/freebsd-powerpc64le/libjnidispatch.so /wrkdirs/usr/ports/java/intellij-ultimate/work/stage/usr/local/share/intellij-ultimate/lib/jna/
install: /wrkdirs/usr/ports/java/intellij-ultimate/work/jna/com/sun/jna/freebsd-powerpc64le/libjnidispatch.so: No such file or directory
Slightly adjusted the patch of Mikael Urankar to make sure it only
affects __arm__ builds.
The patch is similar to what fixed openjdk8 in
commit e13c811372.
Not bumping portrevision as nothing changes for existing pkgs.
PR: 255662
Approved by: java@ (maintainer timeout)
Clang 19 now implements CWG 96 [1], which requires a template argument
list after a 'template' keyword, resulting in errors similar to:
/wrkdirs/usr/ports/java/openjfx14/work/jfx-14.0.2.1-1/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/AbstractMacroAssembler.h:923:65: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
923 | AssemblerType::repatchCompact(dataLabelCompact.template dataLocation(), value);
| ^
/wrkdirs/usr/ports/java/openjfx14/work/jfx-14.0.2.1-1/modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCast.h:146:33: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
146 | return Dispatcher::template inherits(vm, from);
| ^
/wrkdirs/usr/ports/java/openjfx14/work/jfx-14.0.2.1-1/modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/JSCast.h:155:37: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
155 | if (LIKELY(Dispatcher::template inherits(vm, from)))
| ^
/wrkdirs/usr/ports/java/openjfx14/work/jfx-14.0.2.1-1/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntData.h:159:75: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
159 | return reinterpret_cast<LLIntCode>(getCodePtr<tag>(opcodeID).template executableAddress());
| ^
In all these cases, appending "<>" is enough to satisfy the constraint.
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#96
PR: 282473
MFH: 2024Q4
