As I said I cannot reproduce that behaviour and as such cannot help debug the problem
I tried it on three different x86_64 Arch installs,
one VirtualBox VM, one VMWare VM and one native, all three times it worked (outside of a chroot).
As a pacakge fix one could include that after make install one looks whether there is a directory
/usr/lib64 and rename it to /usr/lib (or move all contents if both exist).
Essentially most options for the gdc-git PKGBUILD are straight from gcc's PKGBUILD, so
if it is really an error in the PKGBUILD you could crossreference the two.
Sorry if I'm not much of a help here but without experiencing the problem myself there's not
much I can do.
Search Criteria
Package Base Details: gdc-git
Package Actions
| Git Clone URL: | https://aur.archlinux.org/gdc-git.git (read-only, click to copy) |
|---|---|
| Submitter: | demizer |
| Maintainer: | FFY00 (kozzi) |
| Last Packager: | kozzi |
| Votes: | 17 |
| Popularity: | 0.000000 |
| First Submitted: | 2012-03-23 03:09 (UTC) |
| Last Updated: | 2019-08-23 10:42 (UTC) |
Packages (2)
<deleted-account> commented on 2012-09-09 17:21 (UTC)
svenstaro commented on 2012-09-09 17:09 (UTC)
Also, the automatic chroot that devtools provide is the standard way to build things in Arch as they provide the same environment everywhere. You should really build the package in a chroot and make it work there. I was actually looking at including this package in [community] as gdc and as such it has to work perfectly in a chroot.
svenstaro commented on 2012-09-09 17:08 (UTC)
Same issue outside of a chroot.
<deleted-account> commented on 2012-09-09 17:07 (UTC)
i686 (your logs) installs to /usr/lib, no problem there.
x86_64 (your logs) seems to install to /usr/lib64, but that is imho because you run it in a change root.
gcc uses internal detection to test whether it should install to /lib or to /lib64 on a x86_64 target.
This detection works fine outside of a chroot (just tried it myself), but in a chroot it seems
it defaults to /usr/lib64 because it cannot find any system files (I'm guessing with the last
part as I could not find any hard proof).
So to me this does not seem to be an issue of the package but of gcc.
For now I'd suggest you build the package outside of a chroot, maybe use a tool like yaourt.
If you find a way to circumvent that internal detection I would be happy to
include it in the PKGBUILD.
svenstaro commented on 2012-09-09 16:14 (UTC)
Fresh from this PKGBUILD in a chroot:
x86_64: http://ompldr.org/vZmZlZA
i686: http://ompldr.org/vZmZlZQ
<deleted-account> commented on 2012-09-09 15:47 (UTC)
The PKGBUILD uses the normal make install and it installs to
/usr/lib fine. Please provide the config.log and build.log.
svenstaro commented on 2012-09-09 15:35 (UTC)
Works for me now but the install path of the libs is wrong. It should be /usr/lib and not /usr/lib64.
<deleted-account> commented on 2012-09-05 16:51 (UTC)
Updated to use the gcc snapshot 4.8-20120902
which also works for me.
Svenstaro, if it doesn't build for you please provide the build.log,
since it doesn't seem to be an issue of the package.
Dav1d commented on 2012-09-05 14:44 (UTC)
It compiles with the latest gcc snapshot for me:
_gccver=4.8-20120902
Pinned Comments