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

VJSchneid commented on 2020-03-15 09:31 (UTC)

The isl source url does currently not work for me. I'm getting redirected to http://isl.gforge.inria.fr/. Changing the link from https to http fixes the issue.

jamespharvey20 commented on 2019-10-13 02:28 (UTC)

Temporarily hold to commit fcab78b9 (2019-10-01 18:21:31.) Otherwise, fails to build. There are several breaking commits after this, involving packaging failures on ada and a bootstrap failure when comparing stages 2 and 3.

nitomema commented on 2019-05-09 19:56 (UTC)

Now all USPS employees can make use liteblue portal to get all the benefits. Login to it from https://ncseculogin.website/liteblue-login-liteblue-usps-gov-employee-login/

jamespharvey20 commented on 2019-04-29 23:02 (UTC)

IK4MS, thanks for the report. Just pushed a fix. Two causes. First, PKGBUILD was able to set _majorver to the first character in pkgver, but BASE-VER was just bumped to 10.0.0, because gcc-9-branch was created, GCC 9 rc1 was announced, and 9 is expected to be released as early as late next week. Second was a problem with some of the so names, which has been fixed in trunk since your comment.

IK4MS commented on 2019-04-28 20:29 (UTC)

GCC-Git currently fails to build; Due to a change upstream, /usr/lib/gcc/x86_64-pc-linux-gnu/10.0.0/adalib/libgnarl(at)-1.so and their 32 bit counterpart fails to be found, as they were renamed to libgnarl(at)-9.so.

The package builds just fine by changing references to "${_majorver}" to a simple "9", but I suspect that is a fairly dirty fix.

everythingfunct commented on 2019-02-01 16:53 (UTC) (edited on 2019-02-01 18:54 (UTC) by everythingfunct)

Should flex and bison be added as build depends? It took me a while to figure this out when trying to build a Docker image with this package installed. Or am I just a moron and they are included in the implied base-devel dependency?

Edit: looked it up. Nevermind, I'm the idiot.

jamespharvey20 commented on 2018-12-29 03:10 (UTC)

Upstream revision 267034 (git commit 40caaded 2018-12-11) renamed target 'install-gnatlib' to 'install-libada'.

PKGBUILD has been updated.

The comment and upstream bugreport I made on 2018-12-25 was a red herring. Those errors regarding 'gnatdll' and 'rts/standard.ads.h' appear even on building core's 8.2.1+20180831-1, but do not make the build fail. The "make... ada.install-{common,info}" command was succeeding, even with those errors. It was the "make... install-gnatlib" command after that which was causing the build to fail.

jamespharvey20 commented on 2018-12-25 08:34 (UTC)

git commit 40caaded (2018-12-11) breaks "make ... ada.install-{common,info}" in package_gcc-ada-git().

Reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88591

Temporarily, use its parent by appending "#commit=b686c391" to the git source url to successfully build. I'm expecting this will be a quick upstream fix, so won't push a PKGBUILD with this commit baked in, unless it isn't fixed quickly upstream.

jamespharvey20 commented on 2018-12-17 00:59 (UTC)

Thanks, bz87672.patch has been removed.

Yesterday, I attempted building 9.0.0.r166204.2c4e6da263b, and got a failure in "package_gcc-ada-git()", including:

  • /usr/bin/install: cannot stat 'gnatdll': No such file or directory
  • cp: cannot stat 'rts/standard.ads.h': No such file or directory
  • make: *** No rule to make target 'install-gnatlib'. Stop.

I know 9.0.0.r164385.7961f40be4b worked, on 10/21. I'm trying again, but I'm expecting a failure even on current master. Unless current master now works, there is probably either: an upstream bug introduced in the past 2 months that gets triggered by the way Arch core builds gcc; or an upstream change to 9.0.0 which would necessitate a change to the way Arch builds.

tuckerboniface commented on 2018-12-15 16:36 (UTC)

bz87672.patch can be removed, it was applied upstream.

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