There have been lots of missing CONFLICTS_INSTALL entries, either
because conflicting ports were added without updating existing ports,
due to name changes of generated packages, due to mis-understanding
the format and semantics of the conflicts entries, or just due to
typoes in package names.
This patch is the result of a comparison of all files contained in
the official packages with each other. This comparison was based on
packages built with default options and may therefore have missed
further conflicts with optionally installed files.
Where possible, version numbers in conflicts entries have been
generalized, some times taking advantage of the fact that a port
cannot conflict with itself (due to logic in bsd.port.mk that
supresses the pattern match result in that case).
A few ports that set the conflicts variables depending on complex
conditions (e.g. port options), have been left unmodified, despite
probably containing outdated package names.
These changes should only affect the installation of locally built
ports, not the package building with poudriere. They should give an
early indication of the install conflict in cases where currently
the pkg command aborts an installation when it detects that an
existing file would be overwritten,
Approved by: portmgr (implicit)
For the replacing of the python command, use the default python 3 version instead of hardcoding python 2.7.
Drop the netbeans version from the .desktop file.
Don't use absolute path for the symlink and add a non-versioned.
This also makes netbeans fetchable again, all distfiles prior to 12.6 where removed upsteam [1].
PR: ports/260414 [1]
Reported by: Marko Cupać <marko.cupac@mimar.rs> [1]
In the build of openjfx14 CCACHE_DIR gets lost leading to build failures e.g.
when building as nobody, so add it into ccwrapper and cxxwrapper.
While here remove redundant ${SETENV} in do-build (${_GRADLE_RUN}
already contains ${SETENV})
PR: 260215
The conflict checks compare the patterns first against the package
names without version (as reported by "pkg query "%n"), then - if
there was no match - agsinst the full package names including the
version (as reported by "pkg query "%n-%v").
Approved by: portmgr (blanket)
The do-install-* targets will now automatically install all the
relevant files provided by the port.
Also while here:
- Replace PORTDOCS with pkg-plist entries for greater control over the
docs.
- Move ZIPSRC-only install targets to ZIPSRC_ALL_TARGET.
- Sort pkg-plist.
- Add a comment explaining why the port installs the bundled version of
bcprov.jar.
- Install additional documentation (docs and tls/docs).
Sponsored by: Modirum MDPay
Sponsored by: Klara, Inc.
During an exp-run for llvm 13 (see bug 258209), it turned out that
java/openjdk11 through openjdk13 fail to build with clang 13:
=== Output from failing command(s) repeated here ===
* For target jdk__packages_attribute.done:
These crashes are all caused by the markOop/markOopDesc classes, which
are used to keep track of objects, and which are 'marked' using the low
few bits. (See
https://github.com/openjdk/jdk13u/blob/master/src/hotspot/share/oops/markOop.hpp
).
After some laborious bisecting, I found out that these crashes start
occuring after the upstream commit https://github.com
/llvm/llvm-project/commit/16d03818412 (Return "[CGCall] Annotate this
argument with alignment").
What happens afterwards, is that clang considers the "this" pointer to
always be aligned to the alignment of the actual object, and then
masking or adding a few low bits is not working as expected.
The reason openjdk14 and higher work fine with clang 13, and don't crash
similarly, is that the OpenJDK people completely redid the
markOop/markOopDesc classes in
ae5615c614
("8229258: Rework markOop and markOopDesc into a simpler mark word value
carrier"). E.g, the markOopDesc class was renamed to markWord, and
*stores* a pointer-like value instead of *being* a pointer-like value.
This is a much safer way of handling things.
However, this upstream commit is *very* large, as are a few of its
follow-ups, which is probably the reason why it has not been backported
to JDKs <= 13. I tried manually backporting it, but got lost in many
nasty patch conflicts and problems.
As a workaround, build openjdk8 through 13 with clang12 from the
devel/llvm12 port, for the time being.
In addition, allow openjdk14 through 17 to be built with clang 13, by
adding -Wno-unused-but-set-parameter to the compilation flags.
PR: 258954
Approved by: maintainer timeout (2 weeks)
MFH: 2021Q4
Use a direct URL to Apache's release archive site as it's not mirrored
by upstream mirror sites
Approved by: glewis (port maintainer), arrowd (mentor)
Differential Revision: https://reviews.freebsd.org/D32427
Use a direct URL to Apache's release archive site as it's not mirrored
by upstream mirror sites
Approved by: ale (port maintainer), arrowd (mentor)
Differential Revision: https://reviews.freebsd.org/D32426
Use a direct URL to Apache's release archive site as it's not mirrored
by upstream mirror sites
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D32386
The Experimental AOT and JIT Compiler were remove in OpenJDK17:
https://openjdk.java.net/jeps/410
Remove this configure argument as it causes build failure on aarch64:
configure: error: unrecognized options: --enable-aot
Approved by: portmgr (build fix blanket)
Running java or javac executables fails with:
Error: dl failure on line 910
Error: failed /usr/local/openjdk8/jre/lib/ppc64le/server/libjvm.so, because /usr/local/openjdk8/jre/lib/ppc64le/server/libjvm.so: Undefined symbol "_ZN5frameC1EPlPh"
Changing "ppc64le" to "ppc64" (or powerpc64) resolves the SIGSEGV issue on big endian but breaks little endian, so replace only on powerpc64.
Submitted by: hamiltcl@verizon.net
Approved by: jonc@chen.org.nz (maintainer timeout)
$ make checksum WITH=TEST
===> License GPLv2 accepted by the user
===> openjdk8-8.302.08.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by openjdk8-8.302.08.1 for building
=> No SHA256 checksum recorded for jtreg4.1-b08.tar.gz.
=> No suitable checksum found for jtreg4.1-b08.tar.gz.
=> SHA256 Checksum OK for battleblow-jdk8u-8.302.08.1-jdk8u302-b08.1_GH0.tar.gz.
*** Error code 1
Reported by: Philipp Ost (via ports@ list)
Changes: https://www.jetbrains.com/ruby/whatsnew/2021-2/
While here:
- update the manual page to mention RubyMine instead of IntelliJ IDEA
- clean up old fixes no longer needed:
- type-ahead timeout exceeded
- slow rendering
- Switch (temporarily?) to somewhat more developed GitHub fork
- Add Java 11 support, `do-test' target, and remove GCC dependency
- Optimize away PLATFORM_VER variable and just set the LIBNAME (without
the suffix to make it more obvious that it's a shared object when we
install things, and in the PLIST_FILES)
- Utilize BUILD_WRKSRC and introduce INVOKE_ANT variable to reduce the
tautology in targets' recipes
- When symlinking to ${CC} as local compiler, do not assume it lives as
${LOCALBASE}/bin/${CC} and call `which ${CC}` explicitly
- Garbage-collect commented out `post-patch' target while we're here
PR: 245867
Submitted by: Angelo Polo
Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
USE_GCC=any has been equivalent to USE_GCC=yes in most cases (such
as i386 and amd64 since 12.x and depending on configuration 11.x,
most newer installations on other platforms, and 13.x across the
board).
Since commit 96c17633d9 Mk/bsd.gcc.mk is treating them as
different spellings of the same, so continue the deorbiting of the
USE_GCC=any form and simply replace it with USE_GCC=yes.
This should not make any functional difference at all.
Discussed with: mat, linimon, pkubaj
