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>
a current version of GCC. This reduces churn for individual ports
and further increases consistency (in line with a canonical version
that we introduced with GCC_DEFAULT_VERSION earlier on and the older
USE_FORTRAN=yes).
On the way, make some comments more consistent.
Discussed with: linimon
the GCC run-time.
This extends revision r246991 (2010-01-02) and should not be necessary
in most cases since LDFLAGS already covers linking, but one can always
compile and link in one swoop, and this makes things consistent between
C and C++.
Feature safe: yes
Makefile. For systems where CC is gcc, this has no effect. For systems
where CC is clang, this forces the use of the base GCC suite. (Some
forward compatibility is also covered in the patch.)
Confirmed to have no ill-effects via multiple runs with gcc as CC:
http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp-bcm.20121006012556.pointyhat-west/
and clang as CC:
http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/
This change is necessary (but insufficient) for the upcoming switch to
clang as CC for the tier-1 architectures.
Finally, accept FORCE_BASE_CC_FOR_TESTING as an override for USE_GCC,
for those who wish to help debug ports with clang. It is an absolute
override; it overrides not only the value "any" but also any value such
as "4.4+".
Reviewed by: brooks, gerald
Approved by: maintainer (gerald)
run-time directory of the version of GCC in use.
As a side effect this fixes the inclusion of said directory into
CFLAGS and LDFLAGS (and FFLAGS where applicable). [1]
Reported by: Scott Allendorf <scott-allendorf@uiowa.edu> [1]
USE_GCC=4.6 and USE_GCC=4.6+ and generally whenever the default
version of GCC is employed.
This will significantly benefit tinderboxes and the larger, reasonably
conservative user base by reducing the amount of rebuilds.
Rename _GCC_BUILD_DEPENDS to _GCC_PORT, but still set _GCC_BUILD_DEPENDS
in the end for the sake of some ports relying on that.
PR: 169449
Discussed with: bf
No ports uses this directly any more via USE_GCC=4.5 and for the sake
of those nine that have USE_GCC=4.5+ we transparently rewrite this to
USE_GCC=4.6+ which has already happened for weeks for tinderbox builds.
Feature safe: yes
GCC (the one which also USE_FORTRAN=yes chooses) in case we do have
to install GCC in any case. Only if an acceptable version of GCC
is already present use that one.
This will ease the load on tinderboxes, further the use of current
versions of GCC, and minimize the need to download/carry several
versions of GCC for users of pre-built packages.
PR: 160507
Submitted by: bf
- bsd.port.mk: add INDEX_PORTS, to support INDEX creation for a subset of the ports tree [1]
- bsd.port.mk: call target "install-rc-script" before "post-install" [2]
- [patch] ports/Mk bsd.port.mk order if groups/users are created by package [3]
- [bsd.port.mk] [patch] reaper of the dead: md5 has been in /sbin for a while [4]
- [bsd.port.mk] [patch] remove support for pre 7.x systems (b.*.m) [5]
- [patch] [bsd.port.mk] reaper of the dead: are three variable defintions needed [6]
PR: ports/156575 [1],
ports/139116 [2],
ports/152498 [3],
ports/155983 [4],
ports/155510 [5],
ports/156340 [6]
Submitted by: Florent Thoumie <flz@xbsd.org> [1],
Sergey Skvortsov <skv@freebsd.org> [2],
Olli Hauer <ohauer@FreeBSD.org> [3],
Eitan Adler <lists@eitanadler.com> [4],
Eitan Adler <lists@eitanadler.com> [5],
Eitan Adler <lists@eitanadler.com> [6]
cad/salome and math/freemat needed some adjustments, apart from these
this looks like a far more easy upgrade than previous ones and according
to the upstream developers we do not even need to bump dependent ports
since GNU Fortran 4.4 and 4.5 are sufficiently compatible.
Tested by: erwin (and pointyhat)
processing of USE_GCC directives, the second then takes a concrete
selection coming from the previous or the code handling USE_FORTRAN
via _USE_GCC.
The one user-visible change is that not just users of USE_FORTRAN,
but now also users of USE_GCC set an rpath via CFLAGS and LDFLAGS. [1]
PR: 129518, 142226 [1]
when building with USE_FORTRAN=yes. This makes us use libstdc++.so.6
(and others) brought by this port as opposed to /usr/bin/libstdc++.so.6
that comes with our system compiler which is based on an older version
of GCC 4.2. Newer version of GCC run-time libraries with the same soname
are always backwards compatible.
Feature safe: yes
C++, too, to avoid subtle compatibility problems.
Diagnose the case where an unexpected value is provided for USE_FORTRAN.
Fix the OSVERSION for which lang/gcc34 should be used foor USE_FORTRAN=g77
according to our Porters Handbook.
Add RUN_DEPENDS to the output of the test-gcc target.
PR: 131114
Submitted by: bf2006a@yahoo.com
