Package Details: gcc10 10.5.0-2

Git Clone URL: https://aur.archlinux.org/gcc10.git (read-only, click to copy)
Package Base: gcc10
Description: The GNU Compiler Collection - C and C++ frontends (10.x.x)
Upstream URL: https://gcc.gnu.org
Keywords: gcc
Licenses: GPL-3.0-or-later, LGPL-3.0+, LicenseRef-custom, GFDL-1.3
Submitter: jonathon
Maintainer: severach
Last Packager: severach
Votes: 3
Popularity: 0.016055
First Submitted: 2022-02-28 11:44 (UTC)
Last Updated: 2024-05-31 14:41 (UTC)

Pinned Comments

jonathon commented on 2022-03-10 23:36 (UTC)

Please read the AUR wiki page before reporting issues.

If you are experiencing a build issue then ensure you are not using an AUR helper and are using a clean chroot.

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Score_Under commented on 2022-11-23 11:28 (UTC) (edited on 2022-11-23 11:29 (UTC) by Score_Under)

Taking a leaf out of gcc49's book, I added this to my copy of the pkgbuild:

export LD_PRELOAD=/usr/lib/libstdc++.so

It built successfully, but the tests took a rather long time...

bialy commented on 2022-11-15 16:55 (UTC) (edited on 2022-11-15 16:55 (UTC) by bialy)

Same issue with GCC9 - https://aur.archlinux.org/packages/gcc9 I was able to build GCC9 using docker image base-devel-20210418.0.20194. Packages work after installation on the host OS. I will try to do the same with GCC10

ZhangHua commented on 2022-11-07 03:18 (UTC)

There seems to be a related bug report about building old gcc with new gcc:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Score_Under commented on 2022-11-05 13:56 (UTC)

Trying to build this, makechrootpkg on a clean chroot with base-devel and multilib-devel installed fails with:

msgfmt: /build/gcc10/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib/libicuuc.so.72)

(plus cascading make errors)

Does anyone know a workaround for this?

saburouta commented on 2022-09-06 04:50 (UTC)

Following discussion in other projects affected by recent changes to linux headers, I was able to resolve the enum multiple definition error with this sed hack:

##  Do not include sys/mount.h
cd "${srcdir}"
        for F in `grep 'sys/mount\.h' ./gcc-10.4.0 -Rl`
        do
            echo "${F}"
            sed -i 's|sys/mount\.h|linux/fs.h|g' "${F}"
        done

At the end of prepare.

baloe commented on 2022-08-27 02:10 (UTC)

This does not compile in Manjaro. Exits with make: *** [Makefile:1015: all] Error 2

I ran sudo chrootbuild -c -p gcc10

silverbluep commented on 2022-08-04 06:07 (UTC)

I'm using pure Arch; and I build in clean chroot with lots of ram. I'm getting a silent error. Commenting out the compiler options in the used makepkg.conf make no difference.

I really have no idea whats going on; cannot find a log file anywhere in the build directory inside the chroot. Nothing is helpful; for as long as I can scroll my terminal screen. If anyone have any solutions; I'm all ears; I included the last few lines before makechrootpkg exits

checking for __clog in -lm... no
checking whether the target stat is reliable... yes
checking whether __mingw_snprintf is present... no
checking whether we have a usable __float128 type... yes
checking whether --as-needed/-z ignore works... yes
checking for feenableexcept in -lm... yes
checking whether fpsetmask is present... no
checking for fp_except... no
checking for fp_except_t... no
checking for fp_rnd... no
checking for fp_rnd_t... no
checking for fpsetsticky... no
checking for fpresetsticky... no
checking for fp_trap... no
checking for fp_enable... no
checking for _SOFT_FLOAT defined... no
configure: FPU dependent file will be fpu-387.h
configure: Support for IEEE modules: yes
checking POSIX version of getpwuid_r with 5 arguments... yes
checking whether the target supports hidden visibility... yes
checking whether the target supports symbol aliases... yes
checking whether the target supports __atomic_fetch_add... yes
checking whether pragma weak works... yes
checking whether the target supports weakref... yes
checking whether the target can unlink an open file... yes
checking whether the target has CRLF as line terminator... no
configure: updating cache ./config.cache
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libgfortran.spec
config.status: creating config.h
config.status: executing default-1 commands
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing gstdint.h commands
make[1]: Leaving directory '/build/gcc10/src/gcc-build'
make: *** [Makefile:1015: all] Error 2

vgivanovic commented on 2022-06-23 05:08 (UTC)

@g3tcho: Was your nitpick directed at me? (I'm not taking offense.) If so, I was just using what came with the gcc10 AUR package.

I would imagine that since gcc10 is two major releases behind the latest gcc, that the latest isl might be incompatible with gcc10 -- but I don't know.

g3tchoo commented on 2022-06-16 22:55 (UTC)

nitpicking here, but why not use the upstream source download for isl at https://libisl.sourceforge.io/?

vgivanovic commented on 2022-06-16 22:33 (UTC)

Commenting out the various xxxFLAGS variables didn´t help, nor did running 'makepkg' directly. (I think I had different errors than the ones reported below. Compiling isl fails with "error 2" whatever that means.)

Despite having run thousands of installs from AUR, I don't know what's meant by compiling in a chroot for AUR packages. Of course I know how to chroot (or arch-chroot), but I have never seen or heard the suggestion to run a AUR install in a chroot. (Doesn't that defeat the purpose of the installation, i.e. to install on a working system.?)

What seems to have worked for me is downgrading to gcc-10.2.0-6, gcc-libs-10.2.0-6 and binutils-2.34-5, and then installing using 'yay' gcc10-10.3.0-2 and gcc10-libs-10.3.0-2.

@jonathon Would you consider creating a gcc10-bin (and any other dependencies) package like gcc-10.2.0-6 and gcc-libs-10.2.0-6? Compiling gcc takes a long time...