There is something going on with optimizations on both the old and
new versions.
If you set USE_GCC=any the port will build way faster:
gcc: make 506.90s user 17.86s system 228% cpu 3:49.41 total
clang: make 3913.28s user 23.73s system 211% cpu 31:05.70 total
I added a GCC option for now.
Setting CFLAGS to -O0 will make clang go as fast as gcc.
Explanation still unknown.
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.
