sysutils/uefi-edk2-bhyve and sysutils/memtest86+. Its successors
lang/gcc49 and lang/gcc5 have left the tree already, and lang/gcc6
is scheduled for removal soon.
Thus at least restrict to i386 and amd64, the only two platforms
supported by those two dependant ports.
these older versions of GCC - GCC 4.8, GCC 5, and GCC 6 - which have
been end-of-lifed upstream many moons ago. GCC 8 has been the default
version of GCC in the Ports Collection for a while and as such proven
itself, plus of all versions it is most likely to be present/used.
No functional change, just updated advice to our users.
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
"ldconfig -m <path>" so the order of ldconfig search directories after
package installation is the same as after a reboot. The original command
simply appends the path to the list of directories while the ldconfig rc.d
script uses "sort -u".
Bump lang/gcc* which are known to install libraries with exactly the same
name so the library loaded at runtime depends on the order of the search
directories.
PR: 228046
Approved by: portmgr (antoine)
Since clang++ 6.0.0 now defaults to -std=gnu++14 (similar to g++ 6 and
higher), building gcc48, gcc49 or gcc5 produce quite a number of
"invalid suffix on literal; C++11 requires a space between literal and
identifier" errors. This is because in many places, double quotes are
directly followed by printf helper macros like HOST_WIDE_INT_PRINT.
In gcc 6 and later, spaces were added between the double quotes and the
macros, to fix this issue, but for earlier versions, use a combination
of find, grep and sed to add them mechanically throughout the respective
source trees.
In addition, gcc5 needs a regular patch to fix an incorrect call to
error(), which should have been error_at(). (This was a mismerge by
upstream.)
Approved by: gerald (maintainer)
PR: 224927
MFH: 2018Q1
info is removed) from lang/gcc7 to lang/gcc47, lang/gcc48 and lang/gcc49.
(For more background see revisions 454177 and 454422.)
Reported by: Ports QA Framework, miwi, sobomax
Discussed with: tijl, miwi
Differential Revision: https://reviews.freebsd.org/D10357
but no expiration date at this point (since at least the latter two
still have users in the ports tree and sparc64 relies on the latter).
PR: 222373
Submitted by: Yasuhiro KIMURA <yasu@utahime.org>
- Move ONLY_FOR_ARCHS into the right position of the Makefile.
- Omit a comment describing GCC_VERSION and SUFFIX.
- Do not quote constant strings compared with ${ARCH}. [1]
- Last, but not least the only functional change (and an important one):
Remove headers being created by GCC's fixincludes machinery from
the installation / packaging to avoid breakage when FreeBSD's headers
are changing afterwards. [2]
PR: 221905 [1], 222233 [2]
Submitted by: linimon [1]
associated with it as well as java from CATEGORIES) from this port.
Technically GCC 4.8 only went end-of-life upstream in June 2015, alas
GCC 4.9 and GCC 5 are well established by now and also provide support
for Java (GCJ/libgcj), and this change simplifies this port significantly
and speeds up the build.
In addition to the expected changes to Makefile, pkg-plist, and pkg-descr,
this also removes files/java-patch-hier.
locale set by the user. Add LANG=C and LC_ALL=C at the beginning of
bsd.port.mk and export them so all commands are executed with the C locale.
LC_ALL=C overrides all other LC_* variables. LANG is used by setlocale(3)
as default value for LC_* variables, so normally it isn't used when LC_ALL
is set, but there's code out there that looks at LANG directly so it's safer
to set it as well. The only commands not captured by this are !=
assignments before any inclusion of bsd.port.*mk.
Introduce USE_LOCALE=<locale> that adds LANG=<locale> and LC_ALL=<locale> to
CONFIGURE_ENV and MAKE_ENV so upstream build systems can be executed with a
different locale (e.g. USE_LOCALE=en_US.UTF-8).
PR: 215882
Exp-run by: antoine
Approved by: portmgr (antoine)
(where I updated that port from GCC 4.8.5 to 4.9.4) to lang/gcc48.
Apart from these improvements these two ports used to be more or less
aligned, and not syncing them fully earlier looks like an omission.
Reported by: linimon
GCC can be mis-built, leading to an internal compiler error building
libgcc/libgcov.c, at least on FreeBSD 11.
Adjust OPTIONS_DEFINE_powerpc64 and OPTIONS_DEFAULT_powerpc64
incrementally (with +=) to avoid overwriting settings defined
at the top of the Makefile (or child ports). [1]
Submitted by: swills [1]
Reported by: swills
command-line options. According to POSIX, string comparisons (and
hence sorting) are to be performed based on the locale's collating
order. Alas GNU AWK only does so in POSIX mode, whereas starting
with FreeBSD 11 we do so by default, running into a bug (or false
assumption) with that script used by GCC.
Setting MAKE_ARGS such that AWK is always invoked in the C locale
works around this bug.
PR: 210122, 211742
Submitted by: jkim
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.
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]
