these older versions of GCC - GCC 4.8, GCC 5, and GCC 6 - which have
been end-of-lifed upstream many moons ago. GCC 8 has been the default
version of GCC in the Ports Collection for a while and as such proven
itself, plus of all versions it is most likely to be present/used.
No functional change, just updated advice to our users.
Traceback (most recent call last):
File "scripts/python/make-dist.py", line 294, in <module>
Setup(InstallRoot_CompilerWithPrevious, InstallRoot_CompilerWithSelf)
File "scripts/python/make-dist.py", line 268, in Setup
reload(pylib) or FatalError()
File "/wrkdirs/usr/ports/lang/modula3/work/cm3-b2ce705/scripts/python/pylib.py", line 655, in <module>
if Host.endswith("_NT") or Host == "NT386":
AttributeError: 'NoneType' object has no attribute 'endswith'
Reported by: pkg-fallout
MFH: 2019Q2
Tcl/Tk 8.5 is approaching EOL. It might or might get another patch release with
8.7 is released, but people should have started migrating to 8.6 long ago. See
also the second paragraph in the last 8.5 release announcement from three years
ago here: https://code.activestate.com/lists/tcl-core/15413/
For now, I don't have an EXPIRATION_DATE.
Replace USE_GCC=any with USE_GCC=yes.
New GCC is now needed:
../utils/bitsetUtils.hh:72: error: 'const class std::bitset<64u>' has no member named 'all'
Approved by: mat (mentor)
Differential Revision: https://reviews.freebsd.org/D20602
Eliminate LINUXNAME from port Makefiles. This was just a helper variable
without special meaning outside port Makefiles but several developers have
copied it to new ports where it was then unused, apparently thinking that
it did have some special meaning.
https://gcc.gnu.org/gcc-9/changes.html has a comprehensive overview of
many improvements and changes and https://gcc.gnu.org/gcc-8/porting_to.html
addresses issues you may encounter porting to this new version, though
this release series should have fewer of those than previous ones.
To provide a brief overview of some of the more noticable changes:
GCC's diagnostics now print source code with a left margin showing line
numbers. This is configurable via -fno-diagnostics-show-line-numbers.
Plus there have been lots of further improvements around diagnostic
messages in general as -fopt-info.
As usual a large number of improvements to code generation, including
but by far not limited to the following:
- Switch expansion (into expressions).
- Inliner defaults are tuned to better suit modern C++ codebases,
especially when built with link time optimizations.
- Hot/cold partitioning is now more precise and aggressive.
- Improved scalability for very large translation units.
- Link-time optimization improvements including faster compilation.
A new option -flive-patching=[inline-only-static|inline-clone] has
been introduced to provide a safe compilation for live-patching.
A new pair of profiling options -fprofile-filter-files and
-fprofile-exclude-files help filter which source files are instrumented.
New built-in functions __builtin_expect_with_probability,
__builtin_has_attribute, and __builtin_speculation_safe_value.
Significant effort has been put into refining existing compiler warnings
and adding additional diagnostics. One notable addition is -Wabsolute-value
which warns for calls to standard functions that compute the absolute value
of an argument when a more appropriate standard function is available. For
example, calling abs(3.14) warns because the appropriate function to
compute the absolute value of a double argument is fabs.
The spelling corrector now considers transposed letters, and the threshold
for similarity has been tightened, to avoid nonsensical suggestions.
A new option --completion provides better option completion in a shell
(such as bash).
OpenACC support in C, C++, and Fortran continues to be maintained and
improved. Most of the OpenACC 2.5 specification is implemented.
Version 5.0 of the OpenMP specification is now partially supported in
the C and C++ compilers.
There is now experimental support for the upcoming C2X revision of the
ISO C standard (via the -std=c2x and similar options).
The C++ front end has experimental support for some of the upcoming
C++2a draft features, enabled by the -std=c++2a or -std=gnu++2a options.
This includes range-based for statements with initializer, default
constructible and assignable stateless lambdas, lambdas in unevaluated
contexts, language support for empty data members, allowing pack expansion
in lambda init-capture, likely and unlikely attributes, class types in
non-type template parameters, allowing virtual function calls in constant
expressions, explicit(bool), std::is_constant_evaluated, nested inline
namespaces, etc.
The C++17 implementation is no longer experimental and parallel algorithms
and <execution> and <memory_resource> are available. Using the types and
functions in <filesystem> does not require linking with -lstdc++fs any more.
On the Fortran side asynchronous I/O is now fully supported; FINDLOC and
IS_CONTIGUOUS and other intrinsics have been implemented.
The MAX and MIN intrinsics are no longer guaranteed to return any
particular value in case one of the arguments is a NaN. This conforms
with the Fortran standard and what other Fortran compilers do.
A new option -fdec-include, set also by -fdec, has been added for
compatibility with legacy code. With this option, the INCLUDE directive
is parsed also as a statement, which allows it to be written on multiple
source lines with line continuations.
Support for the Cell Broadband Engine (SPU), and thus powerpcspe on
FreeBSD as well, has been removed for lack of upstream maintainership.
Also there's been a minor ABI change on arm* targets (that GCC warns
about by default, controlled by the -Wpsabi option).
Support for the D programming language has been added to GCC, implementing
version 2.076 of the language and run-time library, though this port does
not enable this yet. Volunteers welcome to test and contribute.
Remove OPTIONS support from library Haskell ports.
Do not install documentation by library Haskell ports.
Remove deprecation notice from library ports, that still needed.
PR: 224083
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D20247
- Add support for CORBA applications that were removed from recent
releases, and enable them by default as they were before. They follow a
separate GH_TAGNAME.
- Remove obsolete GS application.
- SMP is now enabled by default.
lang/erlang-doc, lang/erlang-man: upgrade to 21.3.
- Add missing NO_ARCH.
Differential Revision: https://reviews.freebsd.org/D19911
/usr/local/lib/ruby/site_ruby/2.5/rubygems.rb:283:in `find_spec_for_exe': Could not find 'bundler' (1.13.6) required by your /wrkdirs/usr/ports/lang/rubinius/work/rubinius-3.86/Gemfile.lock. (Gem::GemNotFoundException)
Reported by: pkg-fallout
Proactively add a CONFLICTS statement with the lang/gcc9 port that
should be landing any day now. That'll avoid a PORTREVISION bump
and rebuild at that point.
bin/lto-dump which may be helpful if you employ link-time optimization (LTO).
Forward port r499061 | gerald | 2019-04-15 from lang/gcc8 and gcc8-devel [1]:
GCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
PR: 208120 [1]
Submitted by: tijl [1]
andreast@ has pushed files/patch-amd64-gcc-multilib-support upstream
after the GCC 9.1 release, so this is now on the GCC 9 branch and can
be removed from our tree.
GCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
Do not bump PORTREVISION, since we'll shortly update to a newer snapshot,
just need a consistent baseline when branching the new lang/gcc9 now that
GCC 9.1 has been released.
PR: 208120
Submitted by: tijl
2019-05-08 databases/ruby-odbc: Broken for more than 6 months
2019-05-08 databases/rubygem-dbd-odbc: Broken for more than 6 months
2019-05-08 devel/dlangui: Broken for more than 6 months
2019-05-08 editors/dlangide: Broken for more than 6 months
2019-05-08 emulators/desmume: Broken for more than 6 months
2019-05-08 emulators/yabause: Broken for more than 6 months
2019-05-08 emulators/yape: Broken for more than 6 months
2019-05-08 games/armagetron: Broken for more than 6 months
2019-05-08 games/boswars: Broken for more than 6 months
2019-05-08 games/ceferino: Broken for more than 6 months
2019-05-08 games/chanta: Broken for more than 6 months
2019-05-08 games/d2x-xl: Broken for more than 6 months
2019-05-08 games/drcreep: Broken for more than 6 months
2019-05-08 games/frobtads: Broken for more than 6 months
2019-05-08 games/paintown: Broken for more than 6 months
2019-05-08 games/pykawari: Broken for more than 6 months
2019-05-08 games/stepmania-devel: Broken for more than 6 months
2019-05-08 games/tinymux: Broken for more than 6 months
2019-05-08 games/voxelands: Broken for more than 6 months
2019-05-08 games/voxelands-server: Broken for more than 6 months
2019-05-08 games/warsow: Broken for more than 6 months
2019-05-08 graphics/appleseed: Broken for more than 6 months
2019-05-08 graphics/apvlv: Broken for more than 6 months
2019-05-08 graphics/qslim: Broken for more than 6 months
2019-05-08 graphics/rawstudio: Broken for more than 6 months
2019-05-08 graphics/tulip: Broken for more than 6 months
2019-05-08 lang/qore: Broken for more than 6 months
2019-05-08 mail/milter-manager: Broken for more than 6 months
2019-05-08 math/goblin: Broken for more than 6 months
2019-05-08 math/mosesdecoder: Broken for more than 6 months
2019-05-08 multimedia/asdcplib: Broken for more than 6 months
2019-05-08 net/crtmpserver: Broken for more than 6 months
2019-05-08 net/linuxigd: Abandonware; use net/miniupnpd instead
2019-05-08 net/openafs: Broken for more than 6 months
2019-05-08 security/quantis: Broken for more than 6 months
2019-05-08 sysutils/boxbackup: Broken for more than 6 months
2019-05-08 sysutils/grub2-efi: Broken for more than 6 months
2019-05-08 sysutils/grub2-pcbsd: Broken for more than 6 months
2019-05-08 sysutils/mdcp: Broken for more than 6 months
2019-05-08 sysutils/sbsigntool: Broken for more than 6 months
2019-05-08 www/py-cherrypy-old: Lates version is in tree and no dependent ports
On the way forward port r499061 | gerald | 2019-04-15 from lang/gcc8 [1]:
GCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
PR: 208120 [1]
Submitted by: tijl [1]
at the beginning of what likely is going to be another one year cycle.
files/patch-amd64-gcc-multilib-support has made it upstream after the
creation of the GCC 9 release branch, so we can drop it.
the release of GCC 9.1 (which is in turn the first in that release series).
Last weeks's snapshot actually was still coming from trunk and contained
early development of what is going to become GCC 10 later on, so we skipped
that one.
- Various ARM improvements [1]
- Disable building in qemu-user-static [1]
- Fix test target [1]
PR: 221297
Submitted by: Dmitri Goutnik <dg@syrec.org> [1]
