Arch Linux User Repository

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.

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.

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

I ran sudo chrootbuild -c -p gcc10

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

@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.

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

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...

same problem as everyone else in a clean chroot with a lot of ram

solved commenting CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS in makepkg.conf.

I encountered the same problem encountered by ryunuck, aelzenaar, and gnaggnoyil: the same 'LONG_MIN' undeclared (etc...) in fibheap.c error. I have 64GB of RAM in my box, I actually sat there and tediously monitored memory usage during compilation, and so I can confidently say running out of memory was not the source of the problem. I also compile in a chroot, without any AUR helpers. I'm using Artix, though. Ultimately, I found out that the problem was with my chroot's makepkg.conf: compilation succeeded with everything set to Artix's defaults (other than the packager field), but failed when I tampered with it by specifying -march and a few other things that probably I shouldn't have been doing anyway. I don't have the time right now to test what specifically caused the error, but my understanding is that GCC is extraordinarily finnicky, so I'd start by making sure your chroot is truly clean, irrespective of whether you're on Arch, Artix, Manjaro, etc. Hope that helps.

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.

@gnaggnoyil, you may have missed that the person who commented most recently (ryunuck) says they are using Manjaro and therefore can't post on the Arch forum. I was replying directly to that comment.

If you are having problems building in a dirty environment then using a clean chroot is a sensible approach.

Finally, I'm not sure why it's up to me to work out why you can't build a package, or why AUR comments are more appropriate for troubleshooting than a thread on the forum.