This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. This change is the second attempt at doing this: the
first attempt went in r401072 and was reverted in r401074 because the diff
was bogus and enabled the new MULTILIB option under all platforms instead
of just powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
I'm not sure what happened exactly but I think I committed the change from
the wrong client. The applied change enabled the MULTILIB option for all
architectures and not only powerpc64. Let's just revert the commit and do
it properly from scratch; other things might be wrong so I wanna take a
closer look, and it's best to just revert quickly.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. Waited a week to ensure the change caused nothing to go
horribly wrong but this change is very low risk because it only affects
powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
UNIQUENAME was never unique, it was only used by USE_LDCONFIG and now,
we won't have conflicts there.
Use PKGBASE instead of LATEST_LINK in PKGLATESTFILE, the *only* consumer
is pkg-devel, and it works just fine without LATEST_LINK as pkg-devel
has the correct PKGNAME anyway.
Now that UNIQUENAME is gone, OPTIONSFILE is too. (it's been called
OPTIONS_FILE now.)
Reviewed by: antoine, bapt
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3336
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.
The JAVA frontend doesn't build on DragonFly on any release. The new
OPTIONS_EXCLUDE_${OPSYS} feature is a nice way to avoid the use of
Makefile.DragonFly (most are in dports, but one is in lang/gcc5).
The recent addition of CXXFLAGS to lang/gcc5 prevents Makefile.DragonFly
on lang/gcc5 from being removed outright. There are a couple of options
available to allow its removal, but I'll need to discuss with Gerald.
Approved by: DragonFly blanket
This was causing the gcc packages to be generated with a
/usr/local/libdata/ldconfig/gcc file. All were conflicting. Bump
PORTREVISION to fix packages built during this time.
With hat: portmgr
Reported by: sunpoet
Add CPE information. [1]
Use PKGNAMESUFFIX so that PORTNAME falls back to plain gcc and we
can avoid setting DISTNAME and CPE_PRODUCT. [2]
PR: 198260 [1]
Submitted by: shun.fbsd.pr@dropcut.net [1]
Suggested by: mat [2]
script to assume the BUILD_CONFIG is set to bootstrap-debug, instead of
letting it auto-detect.
With clang 3.5.0 this auto-detection can fail, due to a discrepancy [1]
[2] in its debug information, when objects are produced with and without
-g. When the auto-detection fails, gcc will compare objects with full
debug information during the stage comparisons, and this sometimes
causes those stage comparisons to fail unexpectedly.
[1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141222/250134.html
[2] http://llvm.org/PR22046
Approved by: gerald (maintainer)
Add support for "-fstack-protector-strong". This extends the
WITH_SSP_PORTS Makefile option in FreeBSD which adds "-fstack-protector"
and "-fstack-protector-all" command-line options that add extra code to
check for buffer overflows to ports built that way, cf.
https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Optimize-Options.html
While this was a good first step, those switches offer too little
protection or too much overhead and so Google contributed a balanced
"-fstack-protector-strong". [1]
PR: 186852 [1]
Submitted by: software-freebsd@interfasys.ch [1]
Since FreeBSD 8.4 and FreeBSD 9.1 make(1) do support :tu and :tl as a
replacement for :U and :L (which has been marked as deprecated)
bmake which is the default on FreeBSD 10+ only support by default
:tu/:tl a hack has been added at the time to support :U and :L to ease
migration. This hack is now not necessary anymore
Note that this makes the ports tree incompatible with make(1) from
FreeBSD 8.3 or earlier
With hat: portmgr
Replace USE_BZIP2 by USES=tar:bzip2.
No longer install rebuild-gcj-db48 (which requires bash among others)
and its man page.
Extend full-regression-test by running contrib/test_summary.
Configure with --enable-gnu-indirect-function to enable the "ifunc"
attribute, a GCC extension. [1]
Remove the man7 pages, which we are not packaging, from the staging area
to silence some warnings some are concerned about. [2]
Submitted by: jmg [1], miwi [2]
Discussed with: kib [1], antoine [2]
No longer run ccache-update-links as part of post-install which, in
the world of staging, no longer is what it used to be. Rely on the
existing @exec and @unexec in pkg-plist instead. [3]
which should have been in the last revision.
