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

jamespharvey20 commented on 2015-07-23 20:19 (UTC)

I'll admit I've never used ada, so I'm only familiar with "gnat_util.gpr" from a quick search. I can do some testing on this later, but wanted to respond, in case you already know some of the answers. Looks like "gnat_util.gpr" has been available for quite some time. I am trying to mirror the core repo gcc as much as possible, so I have a few thoughts. I created this PKGFILE by starting with core's, and making only changes necessary to run git master (as well as the newly supported isl 0.15.) Core's patches are removed if and only if they can no longer be used - i.e. they are already committed in the source, or they conflict. 1) Do you know if a manual build, configured to use ada, installs "gnat_util.gpr" by "make install"? 2) If so, the core package creates the gcc-ada package by running make ada.install-common ada.install-info. Perhaps "gnat_util.gpr" isn't installed using these make options, and there needs to be another ada.install-* added. 3) If so, I'd say asking the core package maintainer (Allan) by a core gcc bug report to add this option would be a good way to go, and then I'd mirror that change and it would be included. I searched for gnat_util.gpr in core's bug reports, and it's never been mentioned. Failing all of that, I am comfortable making PKGFILEs that default going one way, but have documented changes (i.e. Uncomment the line below to XYZ, comment the line below to ZYX) that can easily deviate. If needed, and for any reason upstream (core gcc) won't/can't include "gnat_util.gpr", I could add one of these options if it's relatively easy to come up with, or the solution is provided to me. (I assume it's only going to be an additional line or two.)

charlie5 commented on 2015-07-23 12:58 (UTC)

Would it be sensible/possible to include an install of the 'gnat_util.gpr' and associated files as part of the gcc-ada pkg ?

jamespharvey20 commented on 2015-07-19 21:01 (UTC)

Numerous changes pushed, to allow building with current master rather than commit 12dcc3b7 from a few weeks ago. (Naming of standard libstdcxx-abi fixed, so skipping a few weeks of commits is no longer necessary. Although the default standard changed to C++14 the same day the libstdcxx-abi was renamed, it was actually the latter that caused the build error.)

jamespharvey20 commented on 2015-07-07 21:03 (UTC)

REGARDING ERROR ============================== fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ============================== The gcc.gnu.org/git/gcc.git repo has been randomly doing this occasionally for a few moments. If you experience this error, wait a minute, and just try again. You can also run into this if you manually clone the repo.

jamespharvey20 commented on 2015-07-07 20:35 (UTC)

PKGBUILD has been re-written during the transition from aur3 to aur4. Based off the core repo's gcc 5.1.0-5. Replaces the system gcc. A week ago, gcc switched the default standard used to C++14, which has caused many issues. (Primarily commit 97e9c847) The current PKGBUILD checks out commit 12dcc3b7, from earlier in the day when this change was made. If you want to use the actual master code before these issues get ironed out, comment the "git checkout 12dcc3b7" line in pkgver() in the PKGBUILD file.

haawda commented on 2014-04-27 13:01 (UTC)

lucianolorenti, how did you solve your issue? I get exactly the same error message with my gcc-gcj-package for version 4.9.0.

lucianolorenti commented on 2014-02-23 19:56 (UTC)

I'm sorry, an old makepkg.conf was bothering. It compiles fine

Allan commented on 2014-02-23 00:31 (UTC)

Compiles fine here.

lucianolorenti commented on 2014-02-22 23:36 (UTC)

I tried to compile it in a x86_64 and i have the following error: /usr/include/bits/stdio2.h:124:1: error: inlining failed in call to always_inline ‘int vfprintf(FILE*, const char*, __va_list_tag*)’: function body can be overwritten at link time vfprintf (FILE *__restrict __stream, ^ gcc-snapshot/src/gcc-4.9-20140209/libitm/util.cc:35:31: error: called from here vfprintf (stderr, fmt, list);

alucryd commented on 2013-08-28 10:00 (UTC)

Merging into gcc-git.

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