Sure. The first instance I ran into it was at PKGBUILD::build(), at "make -C $CHOST/libstdc++-v3/doc doc-man-doxygen". It failed, expecting there to be a "${srcdir}/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/doc" directory. But, instead, "${srcdir}/gcc-build/" has:
build-x86_64-pc-linux-gnu/
prev-x86_64-pc-linux-gnu/
stage1-x86_64-pc-linux-gnu/
x86_64-pc-linux-gnu/
So, it doesn't actually detect CHOST using "unknown" and give an error. It makes the directories (at least on my system) with "pc" rather than "unknown", so every instance PKGBUILD uses $CHOST points to a non-existant directory.
Off to bed. 6am here.
Search Criteria
Package Details: lib32-gcc-libs-git 13.0.0_r197401.g33be3ee36a7-1
Package Actions
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.000001 |
First Submitted: | 2013-06-26 03:43 (UTC) |
Last Updated: | 2024-03-21 19:26 (UTC) |
Dependencies (17)
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR, lib32-glibc-eac-binAUR, lib32-glibc-eac-rocoAUR)
- binutils (make)
- doxygen (doxygen-gitAUR, doxygen-yapAUR) (make)
- gcc-ada (gcc-ada-gitAUR, gcc-ada-debugAUR, gcc-ada-snapshotAUR) (make)
- gcc-d (gcc-d-gitAUR, gcc-d-snapshotAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- lib32-gcc-libs (lib32-gcc-libs-gitAUR, lib32-gccrs-libs-gitAUR, lib32-gcc-libs-snapshotAUR) (make)
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR, lib32-glibc-eac-binAUR, lib32-glibc-eac-rocoAUR) (make)
- libisl (libisl-gitAUR) (make)
- libmpc (libmpc-gitAUR) (make)
- python (python37AUR, python311AUR, python310AUR) (make)
- zstd (zstd-gitAUR, zstd-staticAUR) (make)
- dejagnu (dejagnu-gitAUR) (check)
- expect (check)
- inetutils (inetutils-gitAUR, busybox-coreutilsAUR) (check)
- python-pytest (check)
- tcl (tcl-fossilAUR, tcl84AUR) (check)
Required by (442)
- alpemix-bin (requires lib32-gcc-libs)
- android-sdk (requires lib32-gcc-libs)
- android-sdk-build-tools (requires lib32-gcc-libs) (optional)
- android-sdk-build-tools-19.1 (requires lib32-gcc-libs)
- android-sdk-build-tools-23.0.1 (requires lib32-gcc-libs)
- android-sdk-build-tools-23.0.3 (requires lib32-gcc-libs)
- android-sdk-build-tools-24 (requires lib32-gcc-libs)
- android-sdk-build-tools-24.0.1 (requires lib32-gcc-libs)
- android-sdk-build-tools-24.0.2 (requires lib32-gcc-libs)
- android-sdk-build-tools-24.0.3 (requires lib32-gcc-libs)
- android-sdk-build-tools-25.0.2 (requires lib32-gcc-libs)
- android-sdk-build-tools-26 (requires lib32-gcc-libs)
- android-sdk-build-tools-26.0.1 (requires lib32-gcc-libs)
- android-sdk-build-tools-26.0.2 (requires lib32-gcc-libs)
- android-sdk-build-tools-26.0.3 (requires lib32-gcc-libs)
- android-sdk-build-tools-27 (requires lib32-gcc-libs)
- android-sdk-build-tools-27.0.1 (requires lib32-gcc-libs)
- android-sdk-build-tools-27.0.2 (requires lib32-gcc-libs)
- android-sdk-build-tools-27.0.3 (requires lib32-gcc-libs)
- android-sdk-build-tools-28 (requires lib32-gcc-libs)
- Show 422 more...
Sources (4)
Latest Comments
« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 Next › Last »
jamespharvey20 commented on 2015-12-13 10:45 (UTC) (edited on 2015-12-13 10:46 (UTC) by jamespharvey20)
Allan commented on 2015-12-13 10:20 (UTC)
Can you point me at where GCC now expects the vendor to be set to something other than "unknown"?
jamespharvey20 commented on 2015-12-13 09:44 (UTC)
NOTE: GCC previously expected to see CHOST declaring vendor to be "unknown" on my system. (i.e. CHOST='x86_64-unknown-linux-gnu'.) On my system, GCC is now expecting to see vendor "pc". (i.e. CHOST='x86_64-pc-linux-gnu'.) Added a workaround so if Arch declares CHOST to be 'x86_64-unknown-linux-gnu' or 'i686-unknown-linux-gnu', it changes the 'unknown' portion to 'pc'.
If this workaround fails on your system, you will receive a compilation error due to a non-existant directory. If this happens, you may have to change the PKGBUILD so _CHOST declares vendor as "softfloat", "hardfloat", or "unknown". (The directory it complains is missing will tell you what vendor value it's expecting.)
jamespharvey20 commented on 2015-12-13 09:38 (UTC)
My apologies. Unexpected multiple severe family health issues. (All turned out well.) Just pushed multiple updates that should take care of everything. There are one or two namcap errors that should be fairly non-consequential documented in the PKGBUILD that I'm going to look into and take care of tomorrow.
thatbrod commented on 2015-12-01 11:56 (UTC) (edited on 2015-12-01 11:56 (UTC) by thatbrod)
Could the owner please either orphan or update the package?
polymer commented on 2015-10-20 13:29 (UTC)
Current version fails when applying patches in prepare(), after commenting these I believe the script tries to use a MakeFile that doesn't exist. I think the PKGBUILD script is buggy or old.
charlie5 commented on 2015-07-25 12:42 (UTC)
Ok, no worries.
I wasn't sure if it was the best way of doing things. I'll stay with the existing gnat_util pkg.
Cheers.
jamespharvey20 commented on 2015-07-25 03:24 (UTC)
Ahh, OK. I made my previous comments thinking it was part of gcc's svn tree. Yeah, it's definitely good to keep it a separate as an Arch package.
charlie5 commented on 2015-07-24 05:55 (UTC)
I appreciate the quick responses, thanks.
I've adopted a few Ada packages, some of which rely on gnat_util.
Yep, gnat_util appears to have been about for a few years but hasn't made it into gcc (i think). The package provides a subset of 'core' ada files relating to system and compiler. It's used by Asis (Ada introspection), GnatColl (A set of general reuseable components), and a few others.
I believe that gnat_util is not 'in' gcc as yet. There is a sourceforge project which provides it tho.
I've made a PKGBUILD for gnat_util, which basically replicates your build of gcc-ada, then applies the sourceforge 'gnat_util' project Makefile to create/install the needed ada file subset (ie 1st build gcc/ada, then build gnat_util, using the just built gcc-build dir as 'input' to the gnat_util build). It appeared to work ok but was slow and a little clumsy.
The PKGBUILD for the old gnat_util package should still be on the old AUR site. If I can help in anyway, pls let me know.
Regards.
Allan commented on 2015-07-24 02:51 (UTC)
The [core] packages contain every file installed with "make install" (or at least I check it does at the start of every major release).
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)