it as well as java from CATEGORIES) from this port.
After GCC 4.7 went end-of-life upstream in June 2014 there isn't much
use of that not better served by newer lang/gcc* ports and it speeds up
the build and simplifies this port significantly.
In addition to the expected changes to Makefile, pkg-plist, and pkg-descr,
this also removes files/java-patch-hier.
438272 to avoid DISTVERSION in this port .
On the way also drop the definition of DISTNAME and simplify the
definition of GCC_VERSION since GCC 4.7 is EOL.
There are two cases:
- The upstream versionning is compatible with our versionning, or using
DISTVERSION's magic leads to a compatible PORTVERSION, use
DISTVERSION. If it is possible to use DISTVERSIONPREFIX and
DISTVERSIONSUFFIX to make it compatible, use them.
- The upstream versionning is not compatible with our versionning, and
DISTVERSION's magic does not lead to a correct PORTVERSION, then set
PORTVERSION to the equivalent of our versionning, and set DISTNAME.
It is possible to use a third variable where you store upstream's
version and use it to compute PORTVERSION and/or DISTNAME, like the
dns/bind9* ports do.
Sponsored by: Absolight
of GCC including lang/gcc:
Only override CONFIGURE_TARGET for amd64 which is x86-64/x86_64 for the
rest of the world including GNU and GCC. For all other architectures
it already defaults to the value we were setting.
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
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
Use PKGNAMESUFFIX so that PORTNAME falls back to plain gcc and we
can avoid setting DISTNAME and CPE_PRODUCT. [2]
PR: 198256 [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)
Due to the way we have been handling PORTREVISION before lang/gcc48 this
requires PORTEPOCH.
Also, since this is now final and stable, no longer bootstrap this port.
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
GCC 4.6.4 to GCC 4.7.3. This entails updating the lang/gcc port as
well as changing the default in Mk/bsd.default-versions.mk.
This adds powerpc64 as a supported architecture (and removes ia64,
though it can be supported by manually installing lang/gcc48).
New binaries %%GNU_HOST%%-gcc-ar47, %%GNU_HOST%%-gcc-nm47, and
%%GNU_HOST%%-gcc-ranlib47 are provided to support link-time
optimization (LTO) which scales significantly better.
And it adds support for indirect functions (IFUNCS), experimental
support for transactional memory in the compiler as well as a supporting
run-time library called libitm, a new string length optimization pass,
and support for atomic operations specifying the C++11/C11 memory model.
Version 3.1 of the OpenMP specification is now supported for the C,
C++, and Fortran compilers.
GCC accepts the options -std=c11 and -std=gnu11 for the C11 revision
of the ISO C standard which inlcude support for unicode strings,
nonreturning functions (_Noreturn and <stdnoreturn.h>), alignment
support (_Alignas, _Alignof, max_align_t, <stdalign.h>), and a
__builtin_complex built-in function.
The C++ frontend now accepts the -std=c++11, -std=gnu++11, and
-Wc++11-compat options and implements many C++11 features of the
language including extended friends syntax, explicit override
control, non-static data member initializers, user-defined literals,
alias declarations, delegating constructors, atomic classes, and more.
The C++ standard library and Fortran frontend have received many
improvements. See http://gcc.gnu.org/gcc-4.7/changes.html for an
extense list of changes; http://gcc.gnu.org/gcc-4.7/porting_to.html
for information on how to port to that new version.
PR: 182136
Supported by: Christoph Moench-Tegeder <cmt@burggraben.net> (fixing many ports)
Tested by: bdrewery (two -exp runs)
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]
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]
Submitted by: jmg [1], miwi [2]
Discussed with: kib [1], antoine [2][3]
No longer add -I${LOCALBASE}/include to CFLAGS.
Since we now configure with --with-gmp=${LOCALBASE} this is no longer
necessary, and due to bugs in binutils (which should not install ansidecl.h
into ${PREFIX}/include) and GCC (which should search its own include
directories with higher priority) can lead to build failures.
port and avoid a package name collision with other GCC ports. This
also allows us to remove LATEST_LINK.
On the way update to the 20131123 snapshot of GCC 4.7.4.
- Switched to automake 1.11.6, see CVE-2012-3386.
- #14669: Fixed extraction of CC from gmp.h.
- Fixed case of intermediate zero real or imaginary part in mpc_fma,
found by hydra with GMP_CHECK_RANDOMIZE=1346362345.
This is on top of the following changes from version 1.0
- Licence change towards LGPLv3+ for the code and GFDLv1.3+ (with no
invariant sections) for the documentation.
- 100% of all lines are covered by tests
- Renamed functions
. mpc_mul_2exp to mpc_mul_2ui
. mpc_div_2exp to mpc_div_2ui
- 0^0, which returned (NaN,NaN) previously, now returns (1,+0).
- Removed compatibility with K&R compilers, which was untestable due
to lack of such compilers.
- New functions
. mpc_log10
. mpc_mul_2si, mpc_div_2si
- Speed-ups
. mpc_fma
- Bug fixes
. mpc_div and mpc_norm now return a value indicating the effective
rounding direction, as the other functions.
. mpc_mul, mpc_sqr and mpc_norm now return correct results even if
there are over- or underflows during the computation.
. mpc_asin, mpc_proj, mpc_sqr: Wrong result when input variable has
infinite part and equals output variable is corrected.
. mpc_fr_sub: Wrong return value for imaginary part is corrected.
Convert to the new LIB_DEPENDS standard and remove hard-coded
.so versions from a couple of dependent ports.
Bump PORTREVISIONS of all dependent ports.
PR: 183141
Approved by: portmgr (bdrewery)
on FreeBSD 10, and amd64 on earlier versions.
SSP_UNSAFE is added to disable in a port if it fails to build, but
this should only be used in rare circumstances such as kernel modules.
Otherwise, the port may just be failing due to lack of respecting
LDFLAGS.
On FreeBSD 10, this uses an ldscript in /usr/lib/libc.so to pull in
libssp_nonshared.a to address issues linking on i386 [1].
On earlier FreeBSD versions the WITH_SSP knob will add -lssp_nonshared
to LDFLAGS on i386. This is not needed on amd64. However, several hundred
ports do not currently respect LDFLAGS, so this support is disabled currently
as it causes build failures if a dependency is looking for the stack_chk
symbols.
Many thanks to jlh@ for this as he had many years of patience in getting
all of the necessary pieces [1][2] in.
[1] http://svnweb.freebsd.org/base/head/lib/libc/libc.ldscript?revision=251668&view=markup
PR: ports/138228 [2]
Submitted by: jlh (bsd.ssp.mk based on)
Reviewed by: bapt
With hat: portmgr
exp-runs done: 37 over a month on 91i386,91amd64,10i386,10amd64
Instead of hardcoding the compiler target as FreeBSD, use the OPSYS
variable to it. This makes no practical difference for FreeBSD, but
it helps DragonFly get properly configured.
Approved by: gerald
