| Git Clone URL: | https://aur.archlinux.org/gcc6.git (read-only, click to copy) |
|---|---|
| Package Base: | gcc6 |
| Description: | The GNU Compiler Collection - C and C++ frontends (6.x.x) |
| Upstream URL: | https://gcc.gnu.org/gcc-6/ |
| Licenses: | GPL, custom, LGPL, FDL |
| Submitter: | svenstaro |
| Maintainer: | valandil |
| Last Packager: | valandil |
| Votes: | 20 |
| Popularity: | 0.000000 |
| First Submitted: | 2018-05-17 20:56 (UTC) |
| Last Updated: | 2025-12-08 18:45 (UTC) |
@xdavidwu Just letting know that I did see your messages, and that I'm working on cleaning up the PKGBUILD a bit more before publishing the fix. If that's too inconvenient I can revert the changes of the offending commit and push a cleaner PKGBUILD later.
Thanks for the link, it was helpful!
The latest commit in PKGBUILD (ea4ffd34ed11) makes this package fails to build.
The commit contains changes that squash pattern matching into double quotes, like this one + rm "${pkgdir}/${_libdir}/libstdc++.so*". This will not work. Double-quotes allow parameter expansion, arithmetic expansion and command subsitution but not pattern matching. The asterisks are treated as literals and do not expand. Reference: POSIX definition of shell command language, section 2.2.3 Double-Quotes. A quick test with echo * (which expands) and echo "*" (which prints the asterisk) indicates that bash seems to do the same thing.
makepkg in a clean container fails at that line (rm "${pkgdir}/${_libdir}/libstdc++.so*").
Forget it. It installs without any file conflicts all right. It did not due to the AUR helper and some ancient aur database.
Sorry for the inconvenience.
I can't reproduce this issue. I rebuilt the latest version (6.5.0-4) in a clean chroot, and was able to install all packages without file conflicts. Can you show the detailed pacman output?
"gcc6" and "gcc6-libs" have conflicting files. As mentioned in former comments they can be installed using pacman's --overwrite flag:
pacman -S --overwrite /usr/lib/gcc/x86_64-unknown-linux-gnu/6.4.1/libstdc++.a,/usr/lib/gcc/x86_64-unknown-linux-gnu/6.4.1/libstdc++.la gcc6 gcc6-libs
But, "libstdc++.a" file is not the same in both packages. Which "libstdc++.a" file should we keep? "gcc6"'s or "gcc6-libs"'?
No worries. gcc can be a pain to build, so I always build the versions of gcc I maintain in a clean chroot.
I'll look into some of the makedepends, I don't recall needing all of them when I maintained the package before it went to community. But my memory might be flawed...
Building in a clean chroot did it, thank you @valandil! I had tried installing gcc6 both with yay and manually with makepkg but both failed.
Here are the steps that worked for me:
Install devtools from the official repos (for the multilib-build command).
Install libart-lgpl from the AUR.
Download this PKGBUILD and run the mutilib-build command mentioned below from the directory where the PKGBUILD is located. If you used an AUR-helper, you find your libarg-lgpl package in the cache folder of the helper (for yay that is ~/.cache/yay/libart-lgpl/....
Now install the build packages using pacman -U gcc6-...pkg.tar.zst
I highly recommend building this package in a clean chroot. This avoids the use of a AUR helper, which sometimes uses /tmp as the stating directory, which often gets filled completely by gcc's build process.
It also provides a clean environment, which minimizes interactions between your current environment and gcc's build process.
Hi,
I was able to build the package in a clean chroot. I suggest you try that as well. Here's the command I used:
multilib-build -- -I /var/cache/pacman/pkg/libart-lgpl-2.3.21-5-x86_64.pkg.tar.zst
Hey there. Build failed for me. Here a makepkg log. It this a problem on my side or does the PKGBUILD need a fix?
https://drive.google.com/file/d/15TF9wvFrSzFwUwSos9e-JbJxsTEQdWSO/view?usp=sharing
Pinned Comments
valandil commented on 2020-08-24 15:06 (UTC)
I highly recommend building this package in a clean chroot. This avoids the use of a AUR helper, which sometimes uses
/tmpas the stating directory, which often gets filled completely by gcc's build process.It also provides a clean environment, which minimizes interactions between your current environment and gcc's build process.