GCC 10 releases, switch to that over lang/gcc10-devel when GCC 10 is
requested.
Use lang/gcc11-devel when GCC 11 is requested, but note that this is
absolutely experimental and subject to constant change and likely
breakage over the next half year at least before that release series
enters stabilization. Use at your own risk.
an upstream release yet, so we need to leverage the gcc10-devel port
which we'll replace by gcc10 once that exists.
This is not intended for production use, but to allow for an -exp run
and preparing other ports.
block of its own as opposed to touching bits and pieces throughout.
Use the opportunity to simplify various aspects, such as the static
tables describing versions of GCC we support and their initialization.
Overall this sheds another 30 lines off what used to me more tricky
Makefile code. It should not change behavior.
of GCC to use based on the specification of USE_GCC.
This is based on the observation that we now only have a single version
of GCC in base, namely GCC 4.2, which is not in ports any longer. And
we limit our choice to either the specific version requested or the
default version of GCC in the ports tree; i.e., we no longer consider
an installed port of any version in between (which is a fringe case
extremely few, if any, users would have experienced, and then only
outside a clean build environment in any case).
Streamline some debugging output accordingly.
Overall this removes some 25 lines of largely complex logic.
dependency on GCC 6 in the Ports Collection is gone, so we can remove
support for USE_GCC=6 and USE_GCC=6+. [1]
This does not remove lang/gcc6 yet, but helps avoid new dependencies,
and GCC 6 has been unmaintained upstream for more than a year.
On the way update two examples to use more current versions of GCC.
Thanks to: tobik [1]
Collection is gone, remove USE_GCC=5 as an option.
This does not remove lang/gcc5 as such, but helps avoid new dependencies
creeping in, in particular since GCC 5 has been unmaintained upstream for
a while.
While building GCC itself we have to use the built GCC libraries to configure
additional parts of GCC and not the libraires from the host.
Install the built 32-bit libraries. This was not done up to now.
PR: 231804
Approved by: gerald@
GCC, from CFLAGS and CXXFLAGS.
This also establishes a good place where to add any additional such
cases in the future.
PR: 230200
Submitted by: rozhuk.im@gmail.com
that has been necessary for the GCC 4.x series and should not see any
new usage anways.
Use more current versions of GCC in examples, choosing the two most
realistic options.
and consequently many of the USES=compiler flavors use the canonical
version of GCC as defined in Mk/bsd.default-versions.mk as well as
the lang/gcc port
With the "new" setup starting with GCC 5 where I have introduced
lang/gcc5-devel for regular snapshots and lang/gcc5 for releases,
and similarly for GCC 6 and onward, we can now leverage lang/gcc5
(and later) for most of the role that lang/gcc used to play -- and
indeed as of today lang/gcc and lang/gcc5 are nearly identical
short of symlinks for gcc, g++, and gfortran binaries that the
former provides.
So now use lang/gcc5 instead of lang/gcc whenever requested via the
USE_GCC framework directly or indirectly.
This is similar to how the python ports work, for example, and it
allows simplifications in Mk/bsd.gcc.mk and Mk/Uses/fortran.mk and
dropping LANG_GCC_IS from Mk/bsd.default-versions.mk. As a next
step lang/gcc is going to become a "hull" essentially only providing
those symlinks and requiring lang/gcc5 (or whatever has been set as
default in Mk/bsd.default-versions.mk).
The variable defined in it are now always available after including
bsd.port.pre.mk.
PR: 210666
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D6933
base system ever again, simplify the GCCVERSION table and logic to not
worry about minimum system versions carrying a certain version of GCC.
This also removes the _GCCVERSION_${v}_R variables and simplifies some
logic and debug output.
default than lang/gcc (currently 4.8).
(I don't fully agree with this implementation but this makes something
like DEFAULT_VERSIONS+=gcc=4.9 in make.conf work correctly.)
Reported by: Luca Pizzamiglio <luca.pizzamiglio@gmail.com>
Approved by: gerald
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)
definition of the former from Mk/bsd.gcc.mk and add the latter --
still set to 4.6 -- to Mk/bsd.default-versions.mk.
Include Mk/bsd.default-versions.mk from Mk/bsd.gcc.mk to tie the
two together.
of some ports using this unexpectedly. There are no further instances
in the tree any more.
If there is an absolute need to refer to the GCC runtime directory that
cannot be covered by CFLAGS, LDFLAGS or the like, use _GCC_RUNTIME.
This hardly ever should be necessary, though. Avoid whenever possible!
USE_GCC=yes has been omitted though.
Remove USE_FORTRAN handling from bsd.port.mk and bsd.gcc.mk.
Minor cleanups in some ports like USE_GMAKE, NOPORTDOCS,...
Exp-run: bdrewery
Approved by: portmgr (bdrewery)
This also removes the g77 option of USE_FORTRAN, and USE_GCC now always
implies a dependency on binutils.
Reviewed by: bapt
Approved by: maintainer (gerald)
but six-and-a-half years after the upstream release of GCC 4.2.0 and
exactly two years after the removal of lang/gcc45 the time has come.
This reduces package name collisions around GCC related ports by 12.5%. [1]
Reported by: bapt [1]
Beware, this version of GCC is _not_ anywhere near ready for production
use. Use at your own risk, and rather don't use it for regular ports.
Submitted by: devzone.my@gmail.com
number schemes between FreeBSD and GCC, correct) the check for a valid
version specified by USE_GCC. [1]
If IGNORE is set, have test-gcc note that instead of showing its usual,
and in that case incorrect and useless, debugging output.
PR: 175252 [1]
Submitted by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp> [1]
a certain version of GCC is in the base, but also check the existence
of /usr/bin/gcc.
This unbreaks systems where GCC is not built as part of the world, and
instead relies on versions of GCC in the Ports Collection there.
PR: 175252
Submitted by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>
