AUR (en) - gcc-git

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: gcc-fortran-git 13.0.0_r197401.g33be3ee36a7-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/gcc-git.git (read-only, click to copy)
Package Base:	gcc-git
Description:	Fortran front-end for GCC (git version)
Upstream URL:	https://gcc.gnu.org
Licenses:	GFDL-1.3-or-later, GPL-3.0-with-GCC-exception
Conflicts:	gcc-fortran
Provides:	gcc-fortran, gcc-multilib, gcc-multilib-git
Replaces:	gcc-multilib-git
Submitter:	Allan
Maintainer:	IslandC0der (ptr1337)
Last Packager:	ptr1337
Votes:	15
Popularity:	0.000041
First Submitted:	2013-06-26 03:43 (UTC)
Last Updated:	2024-03-21 19:26 (UTC)

Dependencies (18)

gcc-git^AUR
libisl.so (libisl)
binutils (make)
doxygen (doxygen-git^AUR) (make)
gcc-ada (gcc-ada-debug^AUR, gcc-ada-git^AUR) (make)
gcc-d (gcc-d-git^AUR) (make)
git (git-git^AUR) (make)
lib32-gcc-libs (lib32-gccrs-libs-git^AUR, lib32-gcc-libs-git^AUR) (make)
lib32-glibc (lib32-glibc-git^AUR, lib32-glibc-linux4^AUR, lib32-glibc-eac^AUR) (make)
libisl (libisl-git^AUR) (make)
libmpc (libmpc-git^AUR) (make)
python (python32^AUR, python37^AUR, python311^AUR, python310^AUR) (make)
zstd (zstd-git^AUR, zstd-static^AUR) (make)
dejagnu (dejagnu-git^AUR) (check)
expect (check)
inetutils (inetutils-git^AUR, busybox-coreutils^AUR) (check)
python-pytest (python-pytest7) (check)
tcl (tcl84^AUR, tcl-fossil^AUR) (check)

Required by (613)

6sv11 (requires gcc-fortran) (make)
abinit (requires gcc-fortran) (make)
acme-sac (requires gcc-multilib)
airwave-git (requires gcc-multilib) (make)
alberta (requires gcc-fortran) (make)
amethyst-player (requires gcc-multilib) (make)
amethyst-player-git (requires gcc-multilib) (make)
amino-git (requires gcc-fortran)
ampi-openmpi (requires gcc-fortran) (make)
aocl-libflame (requires gcc-fortran) (make)
aocl-libflame-aocc (requires gcc-fortran) (make)
aosp-devel (requires gcc-multilib)
arpack-git (requires gcc-fortran) (make)
assert-fortran-git (requires gcc-fortran) (make)
astrotools (requires gcc-fortran) (make)
atlas-lapack (requires gcc-fortran) (make)
atompaw (requires gcc-fortran) (make)
atomsk-git (requires gcc-fortran)
auto-07p-git (requires gcc-fortran)
avl (requires gcc-fortran) (make)
Show 593 more...

Sources (4)

Pinned Comments

DAC324 commented on 2021-09-17 08:04 (UTC)

In addition to the jamespharvey20's sticky comment: The current GCC 12 versions are labelled "Experimental" for a reason. Development is ongoing, and there are still significant bugs. Hence, it is not recommended to use GCC 12 as a daily driver or on production systems.

At the moment, it is not even possible to build a working Linux kernel with GCC 12, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 .

jamespharvey20 commented on 2017-02-15 04:30 (UTC) (edited on 2017-02-15 11:01 (UTC) by jamespharvey20)

*** STICKY *** These gcc*-git packages replace core's gcc* (non-git) packages. Technically, replacing the system gcc-libs can be dangerous. The possibility of a new upstream gcc git commit breaking your system isn't zero. When you compile and install this, you're using the latest git source, so you may be the first Arch user to be using that particular commit. In practice, I haven't seen an Arch user report such a problem for many years. Just understand that if installing these packages causes your computer to eat you, don't have your loved ones blame me. Oh, and know that if things go wrong, all you *should* have to do is uninstall the git version and go back to a previously working git version or even the core version. You might be able to do this while your system is still running, or you might have to do something like boot off an Arch ISO CD.

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 Next › Last »

Allan commented on 2015-12-13 10:20 (UTC)

Can you point me at where GCC now expects the vendor to be set to something other than "unknown"?

jamespharvey20 commented on 2015-12-13 09:44 (UTC)

NOTE: GCC previously expected to see CHOST declaring vendor to be "unknown" on my system. (i.e. CHOST='x86_64-unknown-linux-gnu'.) On my system, GCC is now expecting to see vendor "pc". (i.e. CHOST='x86_64-pc-linux-gnu'.) Added a workaround so if Arch declares CHOST to be 'x86_64-unknown-linux-gnu' or 'i686-unknown-linux-gnu', it changes the 'unknown' portion to 'pc'. If this workaround fails on your system, you will receive a compilation error due to a non-existant directory. If this happens, you may have to change the PKGBUILD so _CHOST declares vendor as "softfloat", "hardfloat", or "unknown". (The directory it complains is missing will tell you what vendor value it's expecting.)

jamespharvey20 commented on 2015-12-13 09:38 (UTC)

My apologies. Unexpected multiple severe family health issues. (All turned out well.) Just pushed multiple updates that should take care of everything. There are one or two namcap errors that should be fairly non-consequential documented in the PKGBUILD that I'm going to look into and take care of tomorrow.

thatbrod commented on 2015-12-01 11:56 (UTC) (edited on 2015-12-01 11:56 (UTC) by thatbrod)

Could the owner please either orphan or update the package?

polymer commented on 2015-10-20 13:29 (UTC)

Current version fails when applying patches in prepare(), after commenting these I believe the script tries to use a MakeFile that doesn't exist. I think the PKGBUILD script is buggy or old.

charlie5 commented on 2015-07-25 12:42 (UTC)

Ok, no worries. I wasn't sure if it was the best way of doing things. I'll stay with the existing gnat_util pkg. Cheers.

jamespharvey20 commented on 2015-07-25 03:24 (UTC)

Ahh, OK. I made my previous comments thinking it was part of gcc's svn tree. Yeah, it's definitely good to keep it a separate as an Arch package.

charlie5 commented on 2015-07-24 05:55 (UTC)

I appreciate the quick responses, thanks. I've adopted a few Ada packages, some of which rely on gnat_util. Yep, gnat_util appears to have been about for a few years but hasn't made it into gcc (i think). The package provides a subset of 'core' ada files relating to system and compiler. It's used by Asis (Ada introspection), GnatColl (A set of general reuseable components), and a few others. I believe that gnat_util is not 'in' gcc as yet. There is a sourceforge project which provides it tho. I've made a PKGBUILD for gnat_util, which basically replicates your build of gcc-ada, then applies the sourceforge 'gnat_util' project Makefile to create/install the needed ada file subset (ie 1st build gcc/ada, then build gnat_util, using the just built gcc-build dir as 'input' to the gnat_util build). It appeared to work ok but was slow and a little clumsy. The PKGBUILD for the old gnat_util package should still be on the old AUR site. If I can help in anyway, pls let me know. Regards.

Allan commented on 2015-07-24 02:51 (UTC)

The [core] packages contain every file installed with "make install" (or at least I check it does at the start of every major release).

jamespharvey20 commented on 2015-07-23 20:19 (UTC)

I'll admit I've never used ada, so I'm only familiar with "gnat_util.gpr" from a quick search. I can do some testing on this later, but wanted to respond, in case you already know some of the answers. Looks like "gnat_util.gpr" has been available for quite some time. I am trying to mirror the core repo gcc as much as possible, so I have a few thoughts. I created this PKGFILE by starting with core's, and making only changes necessary to run git master (as well as the newly supported isl 0.15.) Core's patches are removed if and only if they can no longer be used - i.e. they are already committed in the source, or they conflict. 1) Do you know if a manual build, configured to use ada, installs "gnat_util.gpr" by "make install"? 2) If so, the core package creates the gcc-ada package by running make ada.install-common ada.install-info. Perhaps "gnat_util.gpr" isn't installed using these make options, and there needs to be another ada.install-* added. 3) If so, I'd say asking the core package maintainer (Allan) by a core gcc bug report to add this option would be a good way to go, and then I'd mirror that change and it would be included. I searched for gnat_util.gpr in core's bug reports, and it's never been mentioned. Failing all of that, I am comfortable making PKGFILEs that default going one way, but have documented changes (i.e. Uncomment the line below to XYZ, comment the line below to ZYX) that can easily deviate. If needed, and for any reason upstream (core gcc) won't/can't include "gnat_util.gpr", I could add one of these options if it's relatively easy to come up with, or the solution is provided to me. (I assume it's only going to be an additional line or two.)