After working on (and largely maintaining) our GCC ports for more than
19 years, time has come to hand over the baton. Sadly despite multiple
requests nobody stepped up, so return this port to the pool.
Still happy to provide guidance and a helping hand, for example working
with upstream or on how to operate the (crucial) nightly testers.
This brings 22 back ports for the C++ front end (including some
for coroutines) and three for the Fortran front end.
The 20211002 snapshot did not bring any changes over 20210925, so
we skipped it.
The Python ports install the library libpython3.x.so under $PREFIX/lib,
and they set USE_LDCONFIG, but these libraries are not registered, due
to a missing symlink, and they are not found by `ldconfig -r'.
This commit make them to be registered, and for some reason it helps the
dynamic linker to find them, and this allows to fix an error in
french/aster. It also helps to fix errors in newer releases of math/sage
(not yet ready to be committed due to other problems).
No exp-run, but it has been tested with many ports on several platforms.
PR: 257864
Approved by: koobs (Python team)
MFH: 2021Q4
After working on (and largely maintaining) our GCC ports for more than
19 years, time has come to hand over the baton. Sadly despite multiple
requests nobody stepped up, so return this port to the pool.
Still happy to provide guidance and a helping hand, for example working
with upstream or on operating the (crucial) nightly testers I have been
running.
After working on (and largely maintaining) our GCC ports for more than
19 years, time has come to hand over the baton. Sadly despite multiple
requests nobody stepped up, so return this port to the pool.
Still happy to provide guidance and a helping hand, for example working
with upstream or on operating the (crucial) nightly testers I have been
running.
Thursday, 7 October 2021
Over 120 individual programs plus dozens of programmer libraries and
feature plugins are released simultaneously as part of KDE Gear.
Today they all get new bugfix source releases with updated translations,
including:
* kmail: Fix an infinite SSL error dialog loop
* konqueror: Make it compatible with KIO 5.86.0 and don’t open every
URL in a new window
* libksane: Fix multi page detection with certain scanners
Full announcement:
https://kde.org/announcements/gear/21.08.2/
This brings one back port for the inter procedural optimizers, one
for the general code generators, and three each for the powerpc
back end and the Fortran front end.
During an exp-run for llvm 13 (see bug 258209), it turned out that
lang/erlang and lang/erlang-runtime2[13] fail to build with clang 13.
What appears to happen is that for these versions of erlang, PGO is
enabled, and it first builds a PGO-enabled beam.smp:
gmake[5]: Entering directory '/wrkdirs/usr/ports/lang/erlang/work/otp-OTP-21.3.8.24/erts/emulator'
if utils/gen_git_version amd64-portbld-freebsd14.0/gen_git_version.mk; then touch beam/erl_bif_info.c; fi
echo " PROFILE beam.prof.smp"
PROFILE beam.prof.smp
rm -f obj/amd64-portbld-freebsd14.0/opt/smp/erl*.profraw
set -e; LLVM_PROFILE_FILE="obj/amd64-portbld-freebsd14.0/opt/smp/erlc-%m.profraw" \
ERL_FLAGS="-emu_type prof +S 1" erlc -W -DPGO \
-o obj/amd64-portbld-freebsd14.0/opt/smp test/estone_SUITE.erl > obj/amd64-portbld-freebsd14.0/opt/smp/PROFILE_LOG
after which it does a test run, and uses llvm-profdata to merge the
profiling data into beam_emu_pu.o:
llvm-profdata merge -output obj/amd64-portbld-freebsd14.0/opt/smp/default.profdata obj/amd64-portbld-freebsd14.0/opt/smp/*.profraw
cc -fprofile-instr-use=obj/amd64-portbld-freebsd14.0/opt/smp/default.profdata -Werror=undef -Werror=implicit -Werror=return-type -O3 -fomit-frame-pointer -pipe -fno-omit-frame-pointer -DMAP_NORESERVE=0 -fstack-protector-strong -fno-strict-aliasing -I/wrkdirs/usr/ports/lang/erlang/work/otp-OTP-21.3.8.24/erts/amd64-portbld-freebsd14.0 -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -Iamd64-portbld-freebsd14.0/opt/smp -Ibeam -Isys/unix -Isys/common -Iamd64-portbld-freebsd14.0 -Ipcre -Ihipe -I../include -I../include/amd64-portbld-freebsd14.0 -I../include/internal -I../include/internal/amd64-portbld-freebsd14.0 -c beam/beam_emu.c -o obj/amd64-portbld-freebsd14.0/opt/smp/beam_emu_pu.o
Later, it runs dtrace over all the collected objects, and this dies:
dtrace -G -C -Ibeam \
-s beam/erlang_dtrace.d \
-o obj/amd64-portbld-freebsd14.0/opt/smp/erlang_pu_dtrace.o
... long list of objects ...
dtrace: failed to link script beam/erlang_dtrace.d: an error was encountered while processing obj/amd64-portbld-freebsd14.0/opt/smp/beam_emu_pu.o
gmake[5]: *** [amd64-portbld-freebsd14.0/Makefile:1005: obj/amd64-portbld-freebsd14.0/opt/smp/erlang_pu_dtrace.o] Error 1
gmake[5]: Leaving directory '/wrkdirs/usr/ports/lang/erlang/work/otp-OTP-21.3.8.24/erts/emulator'
Something in beam_emu_pu.o (emitted by clang or llvm 13) is tripping up
dtrace, but I have very little knowledge about dtrace so I need help
here. :)
Now some other erlang runtimes such as lang/erlang-runtime24 *do* build
successfully with clang 13, but this is only because upstream disabled
the PGO feature, as a side effect of
https://github.com/erlang/otp/commit/b165524c732 ("erts: Implement the
BeamAsm JIT"):
--- a/erts/configure.in
+++ b/erts/configure.in
...
@@ -704,6 +719,9 @@ else
fi
fi
+dnl Disable pgo for now
+USE_PGO=false
+
AC_SUBST(USE_PGO)
AC_SUBST(PROFILE_COMPILER)
I am unsure why upstream disabled this "for now", as it has been
disabled for more than a year. So, for now, work around the dtrace
failures by disabling PGO using the configure flag --disable-pgo, when
building with clang >= 13.
PR: 258494
Approved by: maintainer timeout (2 weeks)
MFH: 2021Q4
