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

giacombum commented on 2017-03-30 21:26 (UTC)

I obtain the following error: /bin/sh ./libtool --tag=CC --mode=link /tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/xgcc -B/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -mrtm -Wall -Werror -Wc,-pthread -g -march=native -O2 -fstack-protector-strong -Wl,-O1 -o libitm.la -version-info 1:0:0 -Wl,--version-script,/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc/libitm/libitm.map -rpath /usr/lib/../lib aatree.lo alloc.lo alloc_c.lo alloc_cpp.lo barrier.lo beginend.lo clone.lo eh_cpp.lo local.lo query.lo retry.lo rwlock.lo useraction.lo util.lo sjlj.lo tls.lo method-serial.lo method-gl.lo method-ml.lo x86_sse.lo x86_avx.lo futex.lo libtool: link: /tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/xgcc -B/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -shared -fPIC -DPIC .libs/aatree.o .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o .libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o .libs/futex.o -mrtm -pthread -march=native -Wl,-O1 -Wl,--version-script -Wl,/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc/libitm/libitm.map -Wl,-soname -Wl,libitm.so.1 -o .libs/libitm.so.1.0.0 libtool: link: (cd ".libs" && rm -f "libitm.so.1" && ln -s "libitm.so.1.0.0" "libitm.so.1") libtool: link: (cd ".libs" && rm -f "libitm.so" && ln -s "libitm.so.1.0.0" "libitm.so") libtool: link: ar rc .libs/libitm.a aatree.o alloc.o alloc_c.o alloc_cpp.o barrier.o beginend.o clone.o eh_cpp.o local.o query.o retry.o rwlock.o useraction.o util.o sjlj.o tls.o method-serial.o method-gl.o method-ml.o x86_sse.o x86_avx.o futex.o libtool: link: ranlib .libs/libitm.a libtool: link: ( cd ".libs" && rm -f "libitm.la" && ln -s "../libitm.la" "libitm.la" ) true DO=all multi-do # make make[4]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm' make[3]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm' make[2]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm' make[1]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build' make: *** x86_64-unknown-linux-gnu/libstdc++-v3/doc: No such file or directory. Stop.

jamespharvey20 commented on 2017-02-15 10:53 (UTC)

Awesome. Allan's adding a version to provides did the trick. pacman now installs these gcc*-git packages without issue now, replacing core's non-git packages.

Allan commented on 2017-02-15 04:46 (UTC)

Well... I when originally uploaded this package, it had provides/conflicts/replaces entries. So i guess my opinion is they should be there. Nothing should be installed into /usr/local. People can have this as a standalone gcc-git package does not not replace the system version by adding this to configure: "--program-suffix=-git --enable-version-specific-runtime-libs"

jamespharvey20 commented on 2017-02-15 04:38 (UTC)

@Allan - Thanks! I didn't even get to send my pacman-dev email. :-) By the way, what are your thoughts on replacing (provides/conflicts) the core gcc* packages? Do you think it's appropriate to have a warning posted, since it doesn't seem to have caused a problem for anyone recently? Or, would you urge it to be moved into /usr/local?

Allan commented on 2017-02-15 04:35 (UTC)

You need to add a version to your provides. E.g. provides=('gcc-libs=7.0.1')

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.

jamespharvey20 commented on 2017-02-15 04:26 (UTC) (edited on 2017-02-15 11:03 (UTC) by jamespharvey20)

Apologize I've been quiet while working on some roadblocks. I've pushed changes that as closely as possible makes gcc-git match core's gcc 6.3.1-1. It successfully builds and works. Useful other changes: * Now uses the github mirror repo. I had many times recently where the git clone from the upstream gcc git repo failed, or took even longer than the long time it is expected to take. I've seen this in the past for the official repo also. * Has been updated to parse _pkgver_base, _pkgver, and _libdir, rather than be hardcoded. * Uses isl 0.18 EDIT: The rest no longer applies. See more recent comments. But, I haven't been able to install it using pacman. I haven't ever used pacaur or yaourt, but I'll probably check if those successfully install it somehow. # pacman -S gcc-git gcc-libs-git [I use a local network arch repo, without that, you'd probably be using -U to install, but -U acts the same way] resolving dependencies... looking for conflicting packages... :: gcc-git and gcc are in conflict. Remove gcc? [y/N] y :: gcc-libs-git and gcc-libs are in conflict. Remove gcc-libs? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: icu: removing gcc-libs breaks dependency 'gcc-libs>=4.7.1-5' Trying to remove gcc-libs without accounting for that gcc-libs-git will take its place marks almost every package installed for removal. (Just run pactree --reverse gcc-libs and you'll see almost everything installed.) This used to work. I'm thinking a pacman change must have been made, so it doesn't recognize that the -git version provide the non-git versions, when examining broken dependencies. (EDIT: This is no longer being considered.) That made me consider having gcc*-git install to /usr/local instead for 2 reasons. (1) Replacing the system gcc-libs can be dangerous. In practice, I and others haven't had problems with it recently, but the possible danger remains. (2) It would avoid the pacman issues above. I've almost completed this switch. I'm going to reach out to the pacman devs to see if its current refusal to replace the non-git versions with git versions is desirable or not.

sir_lucjan commented on 2017-02-14 15:24 (UTC)

PKGKBUILD: http://wklej.org/id/3042446/ and my own local repo with gcc-git http://wklej.org/id/3042445/

sleeping commented on 2017-02-14 15:19 (UTC)

I have no interest in ada, so I'd be interested. Maybe it can help jamespharvey20 too.

sir_lucjan commented on 2017-02-08 16:26 (UTC)

I've PKGBUILD but without gcc-ada-git. Are you interesed?

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