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.

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

@jonathon We ARE using Archlinux and by saying "it's a Manjaro issue" you were making false assumptions of us without even asking what we were doing.

This package can be built using devtool, but it DOES report compile error when running makepkg directly or using a AUR helper. Thus, it resulted in some misconceptions about what you were meaning that you insists this package "builds just file on Arch".

If you were indeed unable to reproduce the issue and have no interest of investigating what was happening, please at least just reply with "cannot reproduce, won't fix". I don't think it is a proper reply to make misleading conclusion and then further make false assumptions based on that conclusion.

The package builds just fine on Arch, so given this is currently a Manjaro issue you can post on the Manjaro forum.

If the Manjaro forum will not give you support, and you can't or won't run Arch, then you might look at EndeavourOS or Garuda as derivatives much closer to Arch - where all AUR packages will work as intended.

If you insist on using Manjaro and want support from me then I'm available for hire. Given a sufficient donation I will install Manjaro in a virtual machine and try to replicate the issue. If you are interested then feel free to email me.

Hello! I have the same problem as aelzenaar and gnaggnoyil. I have 32gb of RAM so definitely not the problem, and same result with makepkg.

I cannot post on the forum because I use Manjaro and the rules forbid me from posting there.

✖  make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’:
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:38:25: error: ‘LONG_MIN’ undeclared (first use in this function)
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  220 |   if (okey == key && okey != FIBHEAPKEY_MIN)
      |                              ^~~~~~~~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:36:1: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   35 | #include "fibheap.h"
  +++ |+#include <limits.h>
   36 | 
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:38:25: note: each undeclared identifier is reported only once for each function it appears in
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  220 |   if (okey == key && okey != FIBHEAPKEY_MIN)
      |                              ^~~~~~~~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c: In function ‘fibheap_delete_node’:
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:38:25: error: ‘LONG_MIN’ undeclared (first use in this function)
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  261 |   fibheap_replace_key (heap, node, FIBHEAPKEY_MIN);
      |                                    ^~~~~~~~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:38:25: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
/home/nuck/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’
  261 |   fibheap_replace_key (heap, node, FIBHEAPKEY_MIN);
      |                                    ^~~~~~~~~~~~~~
make[3]: *** [Makefile:758: fibheap.o] Error 1
make[3]: *** Waiting for unfinished jobs....

aelzenaar, gnaggnoyil: there is no error there so you're probably running out of RAM. Also try with makepkg only (rather than a helper), and if you still can't get it working then open a thread on the forum.

@gnaggnoyil I have the same issue, same error in src/gcc/libiberty/fibheap.c on building.

Why didn't you base this on old gcc10 package from repos? people that still have it installed won't get updates from AUR because it had epoch 1 (and other small minor changes in PKGBUILD too)

I ran makepkg and encountered the following error as of today:

if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g -D_FORTIFY_SOURCE=2 -I. -I/home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE -fcf-protection -fpic /home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c -o pic/fibheap.o; \
else true; fi
In file included from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdlib.h:26,
                 from /home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:29:
/usr/include/features.h:412:4: 警告：#warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
  412 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
      |    ^~~~~~~
/home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c: 在函数‘fibheap_replace_key_data’中:
/home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:38:25: 错误：‘LONG_MIN’未声明(在此函数内第一次使用)
   38 | #define FIBHEAPKEY_MIN  LONG_MIN
      |                         ^~~~~~~~
/home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:220:30: 附注：in expansion of macro ‘FIBHEAPKEY_MIN’
  220 |   if (okey == key && okey != FIBHEAPKEY_MIN)
      |                              ^~~~~~~~~~~~~~
/home/gnaggnoyil/.cache/yay/gcc10/src/gcc/libiberty/fibheap.c:36:1: 附注：‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   35 | #include "fibheap.h"
  +++ |+#include <limits.h>
   36 |

Is there anyone that meets the same problem?

The debug option creates a debug package that contains debugging symbols; it was included because it might be useful for people doing development, but apparently it's too confusing so it is now removed from this PKGBUILD as a default. If people want a debug package then they can add the option to the PKGBUILD themselves.

If I didn't want to install the package, I wouldn't be commenting here anyway. Secondly, I need the gcc10 package. I had previously installed gcc9. I had no problem with gcc9. When I see an error, I will of course report it. Normally, there are no debug packages in archlinux at the moment. At least you don't necessarily have to download it. In the gcc10 package, there is no code for the package named gcc10-debug in the PKGBUILD file, but the gcc10-debug package is also installed.

By the way, thanks for developing this package.

Generally speaking, if you don't want a package then don't install it. But, I'll check whether debug is necessary for AUR PKGBUILDs.

Looks like the $HOME directory permissions change is a side-effect of how debug packages are built, and that's going to catch people out too. Hm. Let's remove debug as the default.

Edit: I've done that, no pkgrel bump as no rebuild needed, just don't install the package if you don't want it.

The gcc10-debug package is not included in PKGBUILD, but is installed after compiling.

The permissions of the home folder are also changed.

loading packages... resolving dependencies... looking for conflicting packages...

Packages (4) gcc10-10.3.0-2 gcc10-debug-10.3.0-2 gcc10-fortran-10.3.0-2 gcc10-libs-10.3.0-2

Total Installed Size: 1352.75 MiB Net Upgrade Size: 1138.23 MiB

:: Proceed with installation? [Y/n] (4/4) checking keys in keyring [--------------------------------------------------------------------] 100% (4/4) checking package integrity [--------------------------------------------------------------------] 100% (4/4) loading package files [--------------------------------------------------------------------] 100% (4/4) checking for file conflicts [--------------------------------------------------------------------] 100% (4/4) checking available disk space [--------------------------------------------------------------------] 100% :: Processing package changes... (1/4) upgrading gcc10-libs [--------------------------------------------------------------------] 100% (2/4) upgrading gcc10 [--------------------------------------------------------------------] 100% (3/4) installing gcc10-debug [--------------------------------------------------------------------] 100% warning: directory permissions differ on /home/onur/ filesystem: 700 package: 755 (4/4) upgrading gcc10-fortran [--------------------------------------------------------------------] 100% :: Running post-transaction hooks... (1/3) Arming ConditionNeedsUpdate... (2/3) Removing obsolete cached package files (keeping the latest two)... ==> no candidate packages found for pruning (3/3) Updating mlocate database

1- gcc10-fortran and gcc-fortran conflict. 2- A package called gcc10-debug is also installed. It doesn't show up in the AUR search menu either.

[sudo] password for onur:
loading packages... resolving dependencies... looking for conflicting packages...

Packages (4) gcc10-10.3.0-1 gcc10-debug-10.3.0-1 gcc10-fortran-10.3.0-1 gcc10-libs-10.3.0-1

Total Installed Size: 1352.97 MiB

:: Proceed with installation? [Y/n] (4/4) checking keys in keyring [--------------------------------------------------------------------] 100% (4/4) checking package integrity [--------------------------------------------------------------------] 100% (4/4) loading package files [--------------------------------------------------------------------] 100% (4/4) checking for file conflicts [--------------------------------------------------------------------] 100% error: failed to commit transaction (conflicting files) gcc10-fortran: /usr/share/info/gfortran.info.gz exists in filesystem (owned by gcc-fortran) Errors occurred, no packages were upgraded. -> exit status 1