Package Details: lib32-gcc-libs-git 13.0.0_r197401.g33be3ee36a7-1

Git Clone URL: https://aur.archlinux.org/gcc-git.git (read-only, click to copy)
Package Base: gcc-git
Description: 32-bit runtime libraries shipped by GCC (git version)
Upstream URL: https://gcc.gnu.org
Licenses: GFDL-1.3-or-later, GPL-3.0-with-GCC-exception
Groups: multilib-devel-git
Conflicts: lib32-gcc-libs
Provides: lib32-gcc-libs, libasan.so, libgfortran.so, libgo.so, libubsan.so
Submitter: Allan
Maintainer: IslandC0der (ptr1337)
Last Packager: ptr1337
Votes: 15
Popularity: 0.000000
First Submitted: 2013-06-26 03:43 (UTC)
Last Updated: 2024-03-21 19:26 (UTC)

Required by (437)

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 .. 3 4 5 6 7 8 9 10 11 12 13 Next › Last »

jamespharvey20 commented on 2018-10-22 00:37 (UTC)

Bug reported and fixed upstream. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672

Fix isn't committed yet, so added a .patch, and modified PKGBUILD to use current trunk/master again.

jamespharvey20 commented on 2018-10-19 11:23 (UTC) (edited on 2018-10-19 11:30 (UTC) by jamespharvey20)

Just pushed an update. It's pinned at commit 7961f40b (trunk/master branch, but dated 2018-09-25.) I've tested it with "makepkg" and "extra-x86_64-build".

It's pinned on a commit as of 3 weeks ago, because any more recent than that (starting at 81512c36) gives a compilation failure in gcc's bootstrap stage 3. If I run this offending commit, or even trunk/master's most recent commit, manually with the commands in the PKGBUILD, it builds fine. But, as soon as I run those same commands through "makepkg" ("extra-x86_64-build" internally uses "makepkg") the compilation fails.

I wrote a very detailed post about this here: https://bbs.archlinux.org/viewtopic.php?pid=1813080

I would appreciate any help on this, including a confirmation by someone that this PKGBUILD with 7961f40b builds but that with 81512c36 or trunk/master (remove the "#commit=...") it fails.

You may have success with trunk/master by adding "--disable-bootstrap" as an option to configure. I personally don't want to run a gcc that fails bootstrap stage 3, don't recommend that you do either, and don't feel comfortable releasing one here that uses this option.

jamespharvey20 commented on 2018-10-18 04:33 (UTC) (edited on 2018-10-18 04:36 (UTC) by jamespharvey20)

Sorry, been working on this for the past few days actually.

I just pushed a bunch of commits all at once, rebuilding starting with core's gcc. I re-did all the modifications I've made that weren't pushed yet, in small commits to show small steps, hoping to find a mistake. (BTW, only the most recent pushed commit has a rebuilt .SRCINFO, as the other commits pushed with it at the same time were intended to show steps, and not necessarily be valid within themselves, or be intermediary places to actually use.)

After fixing the issue described below, I will update to use isl-0.20. (Doing so has no effect on the error.) I wouldn't be surprised if there's one or two other modifications to make to actually build the package. (Previously, provides gave basever, this is trying out a full pkgver, etc.)

If I manually follow the steps in the PKGBUILD (run everything in prepare(), the exact same configure, and make) it compiles correctly, and gets me manually to where the end of the PKGBUILD's build() would be.

If I run extra-x86_64-build (devtools, my preference), or even makepkg, it fails to compile, with the error below. This is before the PKGBUILD's build() finishes, specifically in running plain "make".

I've been quite confused. My next step is to look through what makepkg is doing, and hopefully figure out how to reproduce the failure manually and if needed figure out if it's possible to perform an efficient bisect. I'll also be posting on the PKGBUILD forums. Might reach upstream, but I'm not thinking the issue lies there since it compiles just fine outside of makepkg.

I don't know how the other AUR building tools will do, until this is fixed. I wouldn't be surprised if they all use makepkg at some point, so my bet is they will fail.

Using makepkg or extra-x86_64-build (devtools), I get this compilation error in stage 3 of the build (which is a verification step of gcc's build process.)

Full build error here (too hard to post here, AUR takes too much of it as formatting): https://pastebin.com/28dYQqrk

=====

/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200:1: error: invalid operand in unary operation

19200 | output_fix_trunc (rtx_insn insn, rtx operands, bool fisttp)

   | ^~~~~~~~~~~~~~~~

/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200:1: error: incorrect sharing of tree nodes

(ssizetype) _19

_58 = (long unsigned int) ((ssizetype) _19 <= 7 ? 7 - (ssizetype) _19 : 0);

/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200: confused by earlier errors, bailing out

make[3]: *** [Makefile:2287: i386.o] Error 1

SpaceboyRoss commented on 2018-10-18 00:19 (UTC)

==> ERROR: pkgver in provides is not allowed to be empty.

marehr commented on 2018-05-31 14:54 (UTC) (edited on 2018-05-31 15:00 (UTC) by marehr)

Since a recent system update (It might be a pacman update), I can't build this anymore:

makepkg -si

==> ERROR: pkgver in provides is not allowed to be empty.

==> ERROR: An unknown error has occurred. Exiting...

Any help?

ssorgatem commented on 2018-03-16 13:28 (UTC)

It gives an error due to not finding x86_64-pc-linux-gnu/libcilkrts

ssorgatem commented on 2018-03-16 13:27 (UTC)

The packaging step doesn't work

EndlessEden commented on 2017-05-21 00:27 (UTC)

Please update the PKGBUILD to conform with binutils-git(s/binutils>=2.26/binutils>=2.29/)

jamespharvey20 commented on 2017-04-03 01:28 (UTC)

@giacombum. Also, I've never used yaourt before. But, out of curiosity, in a VM, I installed yaourt and successfully built gcc-git 7.0.1.r153096.7714131b8c8-1.

jamespharvey20 commented on 2017-04-02 04:21 (UTC) (edited on 2017-04-02 04:21 (UTC) by jamespharvey20)

@giacombum. This is caused by your CHOST environment variable being set incorrectly. My bet is: (1) in your /etc/makepkg.conf, your CHOST is set to "x86_64-unknown-linux-gnu", rather than "x86_64-pc-linux-gnu"; and (2) there's probably an /etc/makepkg.conf.pacnew file. If this is the case, if you never made custom modifications to makepkg.conf, move the .pacnew file to the .conf file. Read up at https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave, and read through pacman notifications when upgrading packages for the future. Please comment back if this was the issue or not. I ran into the exact failure you're having in late 2015 (you can see comments on this package) when upstream gcc git changed, and no longer expected the vendor portion of CHOST to be "unknown". On a x86_64 platform, it started expecting "pc". In late 2015, I changed this PKGBUILD to have a workaround of changing unknown to pc, which should have worked for everyone on x86_64 platforms. On 2/15/2017, I changed the PKGBUILD to mirror the gcc (non git) package, which was able to avoid this workaround since /etc/makepkg.conf had been changed to use "pc". You'll see in the beginning part of your build, it's properly using "x86_64-pc-linux-gnu". Then, you hit PKGBUILD line 110 (just after running "make") which is "make -C $CHOST/libstdc++-v3/doc doc-man-doxygen" which causes the failure.

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