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
- java/openjdk7* has been removed from the tree since 2022-09-03 however
the relevant codebases in bsd.java.mk has not been removed and the
consumers has also not been updated to use the next jdk version. This
commit updates all relevant consumers to use JAVA_VERSION=8 instead of
JAVA_VERSION=1.7
- Since the introduction of jdk version 18 it looks like similar with
jdk version 8(java version string 1.8). This is prone to error as it
looks similar and is only seperated by a '.'. Remove using
JAVA_VERSION with dotted fomat of java version string and update all
consumers to utilize version 8 instead of 1.8.
Approved by: portmgr (blanket)
During an exp-run for llvm 15 (see bug 265425), it turned out that
databases/db5 failed to build with clang 15.
This is caused by db5's configure script attempting to detect TLS but
encountering internal compiler errors while compiling its test cases,
and then concluding TLS does not work at all:
...
checking whether C++ supports the wstring class... checking for thread local storage (TLS) class... none
...
in config.log it shows what is happening:
configure:19128: checking for thread local storage (TLS) class
configure:19164: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5
conftest.cpp:30:72: error: use of undeclared identifier 'NULL'
template<typename T> __thread T* TLSClass<T>::tlsvar = NULL;
^
Assertion failed: (!isValueDependent() && "Expression evaluator can't be called on a dependent expression."), function isConstantInitializer, file /usr/src/contrib/llvm-project/clang/lib/AST/Expr.cpp, line 3184.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp
1. conftest.cpp:30:76: current parser token ';'
#0 0x00000000053fec51 PrintStackTrace
#/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:13
#1 0x00000000053fcf35 RunSignalHandlers
#/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:104:18
#2 0x00000000053a591e HandleCrash
#/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5
#3 0x00000000053a5ae3 CrashRecoverySignalHandler
#/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51
#4 0x0000000006a1b05e handle_signal
#/usr/src/lib/libthr/thread/thr_sig.c:0:3
c++: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Interestingly enough this compilation error with a fatal crash exists
for a very long time, even back to clang 10 and earlier! But for various
reasons the configure script has always ignored these errors and found
some workaround way to enable TLS anyway.
For now the problem can be fixed by including <stddef.h> at the top of
conftest.cpp, which will allow the TLS test to succeed normally, without
crashing, and the correct result will then be:
configure:19128: checking for thread local storage (TLS) class
configure:19165: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5
conftest.cpp:33:35: warning: unused variable 'x' [-Wunused-variable]
static __thread int x = 0;
^
1 warning generated.
configure:19165: $? = 0
configure:19220: result: modifier
PR: 267156
Approved by: maintainer timeout (>1 month)
MFH: 2022Q4
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
This commit implements such a proposal and moves one of the WWW: entries
of each pkg-descr file into the respective port's Makefile. A heuristic
attempts to identify the most relevant URL in case there is more than
one WWW: entry in some pkg-descr file. URLs that are not moved into the
Makefile are prefixed with "See also:" instead of "WWW:" in the pkg-descr
files in order to preserve them.
There are 1256 ports that had no WWW: entries in pkg-descr files. These
ports will not be touched in this commit.
The portlint port has been adjusted to expect a WWW entry in each port
Makefile, and to flag any remaining "WWW:" lines in pkg-descr files as
deprecated.
Approved by: portmgr (tcberner)
Security: CVE-2019-8457
The SQL option is vulnerable, and since this feature was always marked
experimental, nuke it, and backport to 2022Q1.
If someone needs the SQL interface in spite of its vulnerability,
please use: pkg lock -y db5.
MFH: 2022Q1
I am marking the port for expiry and abandoning it because I will no
longer spend the increasing efforts to play hide and seek with Oracle's
patches, or backport sometimes bigger Linux distro patches (Red Hat,
Debian, who else?), or otherwise put up with how they have changed
availability of patches, documentation, or important information.
FOR db5 USERS:
One option is to upgrade to db18, but note that db versions 6 and 18
are under the Affero GNU GPL v3 license, with implications for,
among others, software-as-a-service, and distributability of packages
linking against db. This is in stark contrast with db5's Sleepycat license.
POTENTIAL MAINTAINERS:
If someone wants to adopt this, review all the various patches in the
major other BSD distros and Linux distros, check if their patches can be
licensed under a sufficiently liberal license (ideally, MIT-like or
Sleepycat) and see what you need to import.
Add JAVA_VERSION="7 8" to db6
Add REWARNFILE=/dev/null to db6 and db5
Reported by: Tommy P <tommyhp2@gmail.com>
PR: 243278
MFH: 2020Q1 (blanket, fix broken build)
* After the deletion of the openjdk6 port, there are no viable versions
of Java 6 left in the ports tree, so remove it as a possible version
PR: 241019
Approved by: mandree@
Sponsored by: The FreeBSD Foundation
Simplify some ports where DragonFlyBSD no longer needs to be special-cased.
Submitted by: rene
Reviewed by: bapt, jbeich
Differential Revision: https://reviews.freebsd.org/D17724
Enable DBM API. [1]
Reorder license information of db5/Makefile to fix portlint warning. [1]
Bump PORTREVISON. [1]
Add command creating symbolic link such as ${PREFIX}/lib/libdb-6.so to
post-install target of db6/Makefile. [1]
Instead of USE_GCC, patch src/dbinc/db.in to not expose the store() macro under C++.
Mark db6 broken on MIPS64 for now, we do not have a workable MUTEX implementation.
Unbreak build on AARCH64, where the db6 autoconfiguration chooses the wrong MUTEX.
PR: 230191
Submitted by: Yasuhiro Kimura
Rather than second-guessing what the __os_free() might be doing and
avoiding it, initialize the pointer to NULL, which __os_free() will
skip. This should be the safer approach if Oracle ever patches other
parts of db 5.3.
PR: 210829
Submitted by: Mark Millard
This currently leaves ARMv6 and aarch64 on FreeBSD 9.x and 10.x out in
the rain because these will still autoconfigure to only permit private
mutexes.
PR: 213167
Submitted by: jbeich (IRC)
The clean up drops an obsolete comment (overcome by a patch),
drops the --disable-tcl that is overridden anyhow, and replaces a few
.if empty(PORT_OPTIONS:Mfoo) by post-install-FOO-{on|off}: targets.
This is to get the port closer to db6.
* Modernize Makefile [1].
* The Tcl changes suggested in the PR [1] are applied but commented out
because the code causes scary "warning: the value of the size argument
in 'strncat' is too large, might lead to a buffer overflow
[-Wstrncat-size]" in lang/tcl/tcl_*.c on FreeBSD 10.3 amd64.
* Other than what is suggested in the PR,
refuse to add the TCL option, and leave --disable-tcl in.
* JAVA option: restrict to Java versions 1.6 and 1.7 because the port
fails to compile with JAVA option enabled and openjdk8
(IllegalArgument exception).
portlint cleanups:
* Set PATCH_WRKSRC, and refresh patches with "make makepatch".
* Use Space (not HTab) after WWW: tag in pkg-descr
* Drop "The" from COMMENT.
PR: 208740 [1]
Submitted by: gahr@ [1]
If portmgr@ needs to commit against better advise, two years after this was
first discussed without any motion of the upstream.
Drop a few more maintainerships along the way.
http://download.oracle.com/otndocs/products/berkeleydb/html/changelog_5_3.htm
- Convert to OptionsNG.
Sunpoet, relative to the PR, there were more Makefile and pkg-plist changes,
as well as an update of Mk/bsd.database.mk and UPDATING.
Port and pkg-plist updates based on
PR: ports/165574
Submitted by: sunpoet@
