aboutsummaryrefslogtreecommitdiffstats
path: root/lang/gcc5
Commit message (Collapse)AuthorAgeFilesLines
* Remove CONFLICT with lang/gcc (which now pulls in lang/gcc5 by default).gerald2017-05-281-1/+1
| | | | | Instead add mutual CONFLICTS between lang/gcc5 and lang/gcc5-devel which we actually missed.
* Make _Unwind_GetIP, _Unwind_GetIPInfo and _Unwind_SetIP available as functionsandreast2017-05-221-0/+51
| | | | | | | | | | for arm*-*-freebsd*. This patch is already pushed upstream to all active gcc branches. GCC-5, GCC-6, GCC-7 and trunk. The gcc?-devel ports will catch up these bits with the next update. Once a new release for gcc6 or gcc5 is done, this patch will be obsolete. Approved by: gerald@ (maintainer)
* - Fix shebangmiwi2017-04-151-1/+4
| | | | Approved by: gerald (maintainer via mail)
* Define WCHAR_T for aarch64 on all active gcc (gcc/gcc5 and gcc6) releases.andreast2017-04-091-1/+6
| | | | | | | | This define is already in upstream. The gcc*-devel ports will pickup the commit from upstream. Submitted by: kan@ Approved by: gerald@ (maintainer)
* Fix armv6 bootstrap. This piece of config is already in the upstream tree andandreast2017-04-061-0/+18
| | | | | | will go away once gcc-5.5 is released. Approved by: gerald (maintainer)
* Sync files/java-patch-hier with the lang/gcc port (the only differencegerald2017-04-031-0/+1
| | | | being a marker to avoid a portlint warning re patch format).
* Pet portlint wrt. patch file format.gerald2017-04-021-1/+1
|
* Add files/patch-x86-64-fix-m16 which already has been accepted ingerald2017-04-022-0/+26
| | | | | | | the upstream GCC 5 branch (and hence is in lang/gcc5-devel) and which we carry in lang/gcc. It should become obsolete when/if GCC 5.5 releases.
* Provide the JAVA option also for powerpc64, in alignment with thegerald2017-04-011-0/+1
| | | | lang/gcc5-devel and lang/gcc ports.
* Update lang/gcc and hence the default version of GCC in the Portsgerald2017-04-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collection (requested by USE_GCC=yes and various USES=compiler invocations) from GCC 4.9.4 to GCC 5.4. files/patch-arm-support and files/patch-gcc_system.h have become obsolete. New patches files/patch-arm-unwind-cxx-support and files/patch-libc++ help support arm targets and new libc++ in base. ONLY_FOR_ARCHS now also includes arm. A new option GRAPHITE_DESC, off by default for now, adds support for Graphite loop optimizations. Finally, conflicts with other lang/gcc* ports are adjusted suitably. In terms of changes for users, this upgrade brings the following: The default mode for C is now -std=gnu11 instead of -std=gnu89. New warning options -Wc90-c99-compat and -Wc99-c11-compat may prove useful on that front. The C++ front end now has full C++14 language support including C++14 variable templates, C++14 aggregates with non-static data member initializers, C++14 extended constexpr, and more. The Standard C++ Library (libstdc++) has full C++11 support and experimental full C++14 support. It uses a new ABI by default. There have been significant improvements to inter-procedural optimizations and link-time optimization such as One Definition Rule based merging of C++ types as well as register allocation. OpenMP 4.0 specification offloading features are now supported by the C, C++, and Fortran compilers. Cilk Plus, an extension to the C and C++ languages to support data and task parallelism, has been added as well. New warning options -Wswitch-bool, -Wlogical-not-parentheses, -Wbool-compare and -Wsizeof-array-argument may prove useful as may new preprocessor directives __has_include, __has_include_next, and __has_attribute. GCC can now be built as a shared library for embedding in other processes (such as interpreters), suitable for Just-In-Time compilation to machine code. This provides a C API and a C++ wrapper API. Many code generation improvements for AArch64, ARM, support for AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally improvements on many targets. The Local Register Allocator (LRA) now contains a rematerialization subpass and is able to reuse the PIC hard register on x86/x86-64 to improve performance of position independent code. https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid overview of issue you may encountering porting to this new version. PR: 216707, 218125 Tested by: antoine (-exp runs) Supported by: jbeich, tcberner, and others
* Backport the bits needed for aarch64-*-freebsd* support from the gcc5-develandreast2017-02-172-2/+188
| | | | | | | port. These bits will go away once GCC releases the next gcc5. Approved by: gerald (maintainer)
* Remove traces of armv6hf which no longer exists as an arch. [1]gerald2017-02-093-41/+2
| | | | | | | | | | Remove files/patch-unwind-ia64.h: we have not been supporting ia64 with this release series, i.e., ONLY_FOR_ARCHS does not include ia64. No PORTREVISION bump since nothing should actually change for existing/supported platforms. Reported by: andreast [1]
* No longer define CPE_VERSION for ports tracking releases of GCC sincegerald2017-02-031-1/+0
| | | | there the default of PORTREVISION is just fine.
* Sort ONLY_FOR_ARCHS.gerald2017-02-021-1/+1
|
* Similar to bug 212465, lang/gcc5 doesn't compile with recent versions ofdim2017-02-011-0/+43
| | | | | | | | | | | | | | | | | | | | libc++, because it attempts to redefine abort(): In file included from /wrkdirs/usr/ports/lang/gcc5/work/gcc-5.4.0/gcc/auto-profile.c:25: In file included from /usr/include/c++/v1/map:446: /usr/include/c++/v1/functional:1398:2: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~~~~~ /usr/include/c++/v1/__config:383:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ Patch this in the same way as the other gcc ports, by including <new> in gcc/system.h, and moving a few includes to before "system.h". Approved by: gerald (maintainer) PR: 216266 MFH: 2017Q1
* The output of tools like awk, date, sort, tr,... depends on the currenttijl2017-01-181-4/+1
| | | | | | | | | | | | | | | | | | 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)
* Omit the definition of DISTVERSION which is only necessary for portsgerald2017-01-161-6/+1
| | | | | tracking snapshots of GCC and simplify the definition of GCC_VERSION (but keep the latter as a variable to align the gcc5-devel and gcc5 ports).
* ${RM} already has -f.mat2016-10-211-4/+4
| | | | | | | PR: 213570 Submitted by: mat Exp-run by: antoine Sponsored by: Absolight
* Mark as broken on sparc64.linimon2016-09-181-0/+1
| | | | Approved by: portmgr (tier-2 blanket)
* Default powerpc64 to bootstrapping (option BOOTSTRAP) since otherwisegerald2016-08-251-2/+2
| | | | | | | | | | | | 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
* Backport the following from lang/gcc5-devel:gerald2016-08-221-2/+0
| | | | | | 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.
* Backport the following from lang/gcc5-devel:gerald2016-08-181-1/+4
| | | | | | | | | | | | | | | GCC uses an AWK script to generate source code that helps process 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
* Update to the GCC 5.4 release.gerald2016-06-064-107/+4
| | | | | | | | files/patch-build-without-bootstrap and files/patch-gcc-freebsd-powerpc64 (ELFv2 support for FreeBSD PowerPC64) are now upstream, so drop them. Due to timeing of the release freeze files/patch-armv6-hf-support has not been integrated in this upstream release yet.
* Skip armv6hf support and move it into armv6.andreast2016-06-041-0/+18
| | | | Discussed with: gerald@
* lang/gcc*: convert to CONFIGURE_OUTSOURCEjbeich2016-04-131-10/+5
| | | | | | | PR: 208294, 208309 Exp-run by: antoine Approved by: gerald (maintainer) Differential Revision: https://reviews.freebsd.org/D4157
* Remove ${PORTSDIR}/ from dependencies, categories h, i, j, k, and l.mat2016-04-011-10/+10
| | | | | With hat: portmgr Sponsored by: Absolight
* Bring the fixes mentioned below from upstream to our gcc-5.3 release port.andreast2016-01-091-2/+52
| | | | | | | | [1]: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02057.html [2]: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00685.html PR: 205394, 205440 Approved by: gerald (maintainer)
* Add two fixes which have missed the gcc-5.3 release date:andreast2015-12-072-0/+54
| | | | | | | - Fix --disable-bootstrap build. - Add ELFv2 support for FreeBSD PowerPC64. Approved by: gerald (maintainer)
* Update to the GCC 5.3 release.gerald2015-12-064-5/+6
| | | | | | Reestablish the GRAPHITE option. Still off by default, as originally. Pet overeager portlint (when it comes to patch format).
* Disable GRAPHITE option for the time being, to be restored later thisgerald2015-12-011-1/+1
| | | | | | | month with the update to GCC 5.3. PR: 204925 Reported by: amdmi3
* Add a MULTILIB option to gcc{,48,49,5} for powerpc64jmmv2015-11-231-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Backport support for Graphite loop optimizations via a new optiongerald2015-11-211-1/+7
| | | | | | | GRAPHITE from gcc5-devel. This is off by default for the time being and pulls in devel/isl as an additional dependency.
* Revert r401072.jmmv2015-11-091-10/+1
| | | | | | | | 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.
* Add a MULTILIB option to gcc{,48,49,5} for powerpc64jmmv2015-11-091-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add missing USES=compiler, needed for ${COMPILER_TYPE} checksantoine2015-10-061-1/+1
| | | | PR: 203540
* Remove deprecated @exec/@unexec from ports using ccache-update-linksantoine2015-09-261-2/+2
|
* Remove UNIQUENAME and LATEST_LINK.mat2015-08-171-1/+0
| | | | | | | | | | | | | | | | | 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
* By default libtool replaces -export-symbols <file> with -retain-symbols-filetijl2015-08-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <file> on ELF systems, but this doesn't really do what -export-symbols is meant to do. On GNU ELF systems it converts <file> to a simple version script first and then uses -version-script instead of -retain-symbols-file. Let USES=libtool patch libtool scripts to do this on all systems with GNU ld(1). Bump PORTREVISION on all ports where the build log contains -export-symbols. audio/calf: This port builds a module that now exports only one function, but it also builds a number of executables that link to this module and expect to see other functions. Because it's already a bit dodgy to link to a module (libtool warns about this) let the module continue to export only one function and instead build an ordinary library from the same source that the executables can link to. Fix a number of other issues in the same Makefile.am and clean up the port Makefile. japanese/scim-honoka: Tries to hide all symbols that start with an underscore, but because this library is written in C++ all symbols start with _Z so it ends up hiding everything. Just don't hide anything at all like the textproc/scim configure script does. multimedia/schroedinger: Apply an upstream patch. textproc/scim-input-pad: Same as japanese/scim-honoka. PR: 201922 Approved by: portmgr (antoine) Exp-run by: antoine
* Update from GCC 5.1 (the first release of GCC 5) to GCC 5.2.gerald2015-07-253-77/+3
| | | | | | This mostly brings bug fixes across teh board plus, thanks to andreast@, support for position independent code directly upstream, so we can remove files/patch-pie-support.
* Backport PIE support for FreeBSD from GCC trunk.andreast2015-06-102-0/+74
| | | | Approved by: gerald
* Merge MASTER_SITES and MASTER_SITE_SUBDIR into just the former.gerald2015-04-291-2/+1
| | | | Suggested by: mat
* Fix MASTER_SITE_SUBDIR.gerald2015-04-281-1/+1
| | | | | Reported by: jbeich Pointy Hat to: whatever injects distcache.FreeBSD.org into my testing
* lang/gcc5: Remove Dragonfly's Makefile; it's no longer neededmarino2015-04-281-9/+0
| | | | | | | | Now that the JAVA exclusion is part of the main Makefile, the only thing Makefile.DragonFly was doing was supporting pre-gcc5 dev branch. Those users have a static package available to them, and in general they are expected to upgrade to post-gcc5 in base anyway. Thus the DF makefile is no longer necessary.
* Update to the 5.1 release, the first release of the GCC 5 series.gerald2015-04-282-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default mode for C is now -std=gnu11 instead of -std=gnu89. New warning options -Wc90-c99-compat and -Wc99-c11-compat may prove useful on that front. The C++ front end now has full C++14 language support including C++14 variable templates, C++14 aggregates with non-static data member initializers, C++14 extended constexpr, and more. The Standard C++ Library (libstdc++) has full C++11 support and experimental full C++14 support. It uses a new ABI by default. There have been significant improvements to inter-procedural optimizations and link-time optimization such as One Definition Rule based merging of C++ types as well as register allocation. OpenMP 4.0 specification offloading features are now supported by the C, C++, and Fortran compilers. Cilk Plus, an extension to the C and C++ languages to support data and task parallelism, has been added as well. New warning options -Wswitch-bool, -Wlogical-not-parentheses, -Wbool-compare and -Wsizeof-array-argument may prove useful as may new preprocessor directives __has_include, __has_include_next, and __has_attribute. GCC can now be built as a shared library for embedding in other processes (such as interpreters), suitable for Just-In-Time compilation to machine code. This provides a C API and a C++ wrapper API. Many code generation improvements for AArch64, ARM, support for AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally improvements on many targets. The Local Register Allocator (LRA) now contains a rematerialization subpass and is able to reuse the PIC hard register on x86/x86-64 to improve performance of position independent code. https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid overview of issue you may encountering porting to this new version.
* Update to the 20150421 snapshot of GCC 5.0.1 -- nearly the 5.1 release.gerald2015-04-232-3/+3
|
* Update the comment that describes the relationship of PORTVERSION andgerald2015-04-201-1/+1
| | | | GCC_VERSION.
* Update to the 20150414 snapshot of GCC 5.0.1 and adjust to thisgerald2015-04-192-4/+4
| | | | | | particularity of the new GCC versioning scheme where the third component of the version number is bumped when the release branches. Use three component version numbers again.
* Update to the 20150405 snapshot of GCC 5.0.gerald2015-04-062-3/+3
|
* Update to the 20150329 snapshot of GCC 5.0.gerald2015-04-032-4/+3
|
* lang/gcc(46,47,48,49,5): Use OPTIONS_EXCLUDE_DragonFly to block JAVAmarino2015-03-272-2/+1
| | | | | | | | | | | | 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
* Fix UNIQUENAME not being unique after recent PORTNAME shuffle.bdrewery2015-03-241-0/+2
| | | | | | | | | 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
* Update to the 20150322 snapshot of GCC 5.0.gerald2015-03-232-3/+3
|
* Add CPE information. [1]gerald2015-03-231-3/+6
| | | | | | | | | 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]
* lang/gcc5: Support DragonFly's gcc50 base compiler in specific scenariomarino2015-03-181-0/+8
|
* Update to the 20150315 snapshot of GCC 5.0.gerald2015-03-162-3/+3
|
* Update to the 20150308 snapshot of GCC 5.0.gerald2015-03-112-3/+3
|
* Update to the 20150301 snapshot of GCC 5.0.gerald2015-03-082-3/+3
|
* Update to the 20150222 snapshot of GCC 5.0.gerald2015-02-252-3/+3
|
* Update to the 20150215 snapshot of GCC 5.0.gerald2015-02-162-3/+3
|
* Update to the 20150208 snapshot of GCC 5.0.gerald2015-02-112-3/+3
|
* Update to the 20150201 snapshot of GCC 5.0.gerald2015-02-022-10/+5
| | | | | | | This now successfully builds libffi again, so we can enable JAVA by default on i386 and amd64. PR: 197171
* Also disable Java and libffi on amd64 until the next snapshot ofgerald2015-01-301-3/+3
| | | | | | GCC 5.0. PR: 197171
* Allow to build gcc for armv6(hf).andreast2015-01-282-1/+116
| | | | Approved by: gerald (maintainer)
* Update to the 20150125 snapshot of GCC 5.0. Sadly libffi is stillgerald2015-01-262-3/+3
| | | | broken thus Java remains disabled on i386.
* Update to the 20150118 snapshot of GCC 5.0.gerald2015-01-263-5/+10
| | | | | | | | libgcj-5.0.pc is now properly called libgcj-5.pc; adjust pkg-plist. libffi is broken on FreeBSD i386 since 2015-01-11, cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779, so disable it for the time being.
* Update to the 20150111 snapshot of GCC 5.0.gerald2015-01-122-3/+3
| | | | | | Welcome FreeBSD/ARM support to upstream GCC! [1] Thanks to: andreast [1]
* Update to the 20150104 snapshot of GCC 5.0.gerald2015-01-092-3/+3
|
* Update to the 20141228 snapshot of GCC 5.0.gerald2015-01-022-3/+3
|
* When building the gcc ports using a full bootstrap, tell the configuredim2014-12-311-0/+1
| | | | | | | | | | | | | | | | 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)
* Update to the 20141221 snapshot of GCC 5.0.gerald2014-12-262-3/+3
|
* Update to the 20141214 snapsho of GCC 5.0.gerald2014-12-212-3/+3
|
* Update to the 20141130 snapshot of GCC 5.0.gerald2014-12-012-3/+3
|
* Update to the 20141123 snapshot of GCC 5.0. Keep in mind that thisgerald2014-11-242-3/+3
| | | | now defaults to the C11 standard, not C89 any more.
* Update to the 20141116 snapshot of GCC 5.0.gerald2014-11-222-7/+3
| | | | This no longer breaks on FreeBSD 10.0 and later using clang.
* Update to the 20141109 snapshot of GCC 5.0.gerald2014-11-162-3/+7
| | | | | Mark IGNORE on FreeBSD 10.0 and later; an upstream fix should make it into the next snapshot.
* Update to the 20141102 snapshot of GCC 5.0.gerald2014-11-032-3/+3
|
* Update to the 20141026 snapshot of GCC 5.0.gerald2014-10-273-4/+3
| | | | Remove last instance of @dirrm in pkg-plist.
* Update to the 20141019 snapshot of GCC 5.0.gerald2014-10-212-5/+3
| | | | | Remove all traces of @dirrm from pkg-plist that are dynamically generated via the Makefile.
* Update to the 20141005 snapshot of GCC 5.0.gerald2014-10-072-4/+3
|
* Comment out info/dir filesbapt2014-10-072-1/+2
| | | | | | indexinfo is taking care of generating it at package installation time Reported by: peter
* Update to the 20140921 snapshot of GCC 5.0.gerald2014-09-283-7/+3
| | | | Remove four instances of @dirrm from pkg-plist.
* Update to the 20140914 snapshot of GCC 5.0.gerald2014-09-183-4/+4
| | | | | On the packaging side this adds another Python script coming from the libstdc++ side of things.
* Add USES=libtooltijl2014-09-111-4/+3
|
* Update to the 20140907 snapshot of GCC 5.gerald2014-09-112-3/+3
|
* Update to the 20140831 snapshot of GCC 5.gerald2014-09-022-3/+3
|
* Update to the 20140824 snapshot of GCC 5.gerald2014-08-252-3/+3
|
* Update to the 20140817 snapshot of GCC 5, which is how GCC 4.10 is nowgerald2014-08-234-12/+12
| | | | going to be called.
* GCC 4.10 has been renamed to GCC 5 upstream; rename our gcc410 portgerald2014-08-238-0/+285
to gcc5 accordingly.