Reimplement ONLY_FOR_ARCHS such that we know that this port requires newer
compiler features (which aren't very clear from the port itself). Probably
need to validate this on powerpc as we have clang available and gcc ports.
PR: 197132
on non-clang architechtures. In addition, if there is no lang/gcc available
for the architecuture, we can't build it via that method either.
Rework archtecture disable to use ONLY_FOR_ARCHS and give a clearer reason
why this is being disabled on powrepc/mips/sparc64.
PR: 197132
Reviewed by: osa@freebsd.org (maintainer)
to unbreak x11-fm/sushi on FreeBSD 8 and 9.
lang/gjs and lang/spidermonkey24 are currently built with
USES=compiler:c11. On FreeBSD 8, this causes them to be compiled
with clang from ports, and on FreeBSD 9, they are built with clang
from base. In both cases, they are linked to libstdc++ from base.
These two ports are dependencies of x11-fm/sushi, which also depends
on webkit-gtk3, which is compiled with USES=compiler:c++11-lib. On
FreeBSD 8 and 9 webkit-gtk3 is compiled with gcc from ports and
linked to its newer bundled libstdc++. Sushi is compiled with gcc
from base and consists of pure C code, so it does not link directly
to libstdc++. The build fails because ld links in the base version
of libstdc++ before it links in webkit-gtk3, and then discovers
that the newer libstdc++ ABI needed by webkit-gtk3 is missing.
Converting sushi to USES=compiler:c++11-lib does not fix the build
failure, and just changes the error message, probably because sushi
does not directly link to any version of libstdc++. If sushi is
further hacked to force it to link directly to the newer version
of libstdc++ bundled with the gcc port, the build succeeds, but the
resulting executable segfaults inside libstdc++ with a stack trace
that traverses a bunch of functions contained in the gjs and
spidermonkey24 libraries.
Converting gjs and spidermonkey24 to USES=compiler:c++11-lib forces
them to be compiled with the ports version of gcc on FreeBSD 8 and
9 and link to its bundled libstdc++ (and is a no-op on FreeBSD 10
and higher). Because these libraries are linked into sushi before
webkit-gtk3, they load the version of libstdc++ which meets the
requirements of webkit-gtk3, and the resulting executable is
functional. No modifications to sushi are necessary.
PR: 196078, 199434, 199435
Differential Revision: https://reviews.freebsd.org/D2396
Approved by: mat (mentor)
MFH: 2015Q2
PR: 195736
Submitted by: Michael Gruenewald (maintainer)
Add'l fixes: marino
Besides typical port cleanup, the dragonfly patches which had been
removed for the update were added back to the configure patch.
When using GH_TAGNAME the DISTNAME would have GH_PROJECT and GH_ACCOUNT in
it. When not using GH_TAGNAME it would not have this. Now both cases
will add in the GH_PROJECT and GH_ACCOUNT.
Add special care to ensure that the DISTVERSION is not added in twice. If
a port does GH_TAGNAME=v${PORTVERSION} it will be added in twice though. For
that case DISTVERSIONPREFIX=v should be set and no GH_TAGNAME should be used.
empty() is used rather than (!defined || !${}) to support fmake.
The purpose of setting DISTNAME at all in these cases is to make it more clear
that the distfile is from *GITHUB* and to avoid collisions if a project were
to be renamed or moved. Without adding in GH_PROJECT and GH_ACCOUNT then there
are real risks that collisions on filenames would happen on renamed or moved
projects, which is fairly common. A GITHUB-generated file may not match
a custom-rolled or git-archive-rolled distfile.
PR: 199069
With hat: portmgr
Testing done: All USE_GITHUB ports without GH_COMMIT were checksum/fetch/extract/WRKSRC tested.
The original intention was to build update all the bootstrap compilers
to be based on GCC5, but right now I'm only doing that for DragonFly.
After June 30, I might rebuild the bootstrap compiler on FreeBSD 10.1,
but right now gcc5-aux is building fine on FreeBSD in one stage, even
though their bootstrap is based on GCC 4.9.
Right now, gcc5-aux is building with 3 full stages. I'm switching it to
a single stage build, but adding an off-by-default option to build it
in three stages again. With one stage, libcc1 is not built, but with
three stages it is. LibCC1 is meant to support the upcoming release of
GDB so it's currently not needed (it fails to build if gcc is not fully
bootstrapping which is why it's disabled)
This brings the build down to about 9-14 minutes versus 60-90 minutes
depending on the (average power) machine.
Also, I've explicitly limited the build to i386 and amd64 on FreeBSD and
I have dropped i386 support on DragonFly, which could only have been
build on DragonFly 3.8 or earlier.
Also, I removed the iconv dependency when a bootstrap compiler is being
created (the all-overriding BOOTSTRAP option for the maintainer)
Swapping LIBS with LDFLAGS and removing the *_configargs definitions
allows gcc5-aux to build on all supported platforms. Now that gcc5 has
been released, new bootstrap compilers should be created for both FreeBSD
and DragonFly in order remove bootstrapping requirement (previously
gcc5 built live but not in poudriere, reason still unknown).
Now that the JAVA exclusion is part of the main Makefile, the only thing
Makefile.DragonFly was doing was supporting pre-gcc5 dev branch. Those
users have a static package available to them, and in general they are
expected to upgrade to post-gcc5 in base anyway. Thus the DF makefile
is no longer necessary.
The default mode for C is now -std=gnu11 instead of -std=gnu89.
New warning options -Wc90-c99-compat and -Wc99-c11-compat may
prove useful on that front.
The C++ front end now has full C++14 language support including
C++14 variable templates, C++14 aggregates with non-static data
member initializers, C++14 extended constexpr, and more.
The Standard C++ Library (libstdc++) has full C++11 support and
experimental full C++14 support. It uses a new ABI by default.
There have been significant improvements to inter-procedural optimizations
and link-time optimization such as One Definition Rule based merging of C++
types as well as register allocation.
OpenMP 4.0 specification offloading features are now supported by the C,
C++, and Fortran compilers. Cilk Plus, an extension to the C and C++
languages to support data and task parallelism, has been added as well.
New warning options -Wswitch-bool, -Wlogical-not-parentheses,
-Wbool-compare and -Wsizeof-array-argument may prove useful as
may new preprocessor directives __has_include, __has_include_next,
and __has_attribute.
GCC can now be built as a shared library for embedding in other processes
(such as interpreters), suitable for Just-In-Time compilation to machine
code. This provides a C API and a C++ wrapper API.
Many code generation improvements for AArch64, ARM, support for
AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
improvements on many targets.
The Local Register Allocator (LRA) now contains a rematerialization
subpass and is able to reuse the PIC hard register on x86/x86-64 to
improve performance of position independent code.
https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
overview of issue you may encountering porting to this new version.
While the feature has a great value, it is right now breaking the build of
lang/gcc. Given the importance of lang/gcc it is better to revert now and
reapply the patch once it has been fixed and passes an exp-run on all supported
version
With hat: portmgr
Upstream gcc 4.8 doesn't have support for this - it'll create threads,
but it won't do any of the thread affinity stuff for FreeBSD.
This allows for OMP_PROC_BIND=true to bind threads to their initial
CPUs, leading to some pretty drastic improvements in performance
for certain NUMA workloads.
Approved by: gerald
Sponsored by: Norse Corp, Inc.
Upstream gcc 4.8 doesn't have support for this - it'll create threads,
but it won't do any of the thread affinity stuff for FreeBSD.
This allows for OMP_PROC_BIND=true to bind threads to their initial
CPUs, leading to some pretty drastic improvements in performance
for certain NUMA workloads.
Approved by: gerald
