Package Details: gdc-git 10.0.0+v2.086.0-2

Git Clone URL: https://aur.archlinux.org/gdc-git.git (read-only, click to copy)
Package Base: gdc-git
Description: Compiler for D programming language which uses gcc backend
Upstream URL: https://gcc.gnu.org/
Licenses: GPL3
Conflicts: gcc-gdc, gdc
Provides: d-compiler, gdc
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)

Required by (16)

Sources (3)

Pinned Comments

Latest Comments

kozzi commented on 2019-08-07 12:41 (UTC)

To build this package you need to have working gdc compiler, because gdc in [community] is broken right now and will be until FS#62726 is fixed, you can use gdc-static from AUR: https://aur.archlinux.org/packages/gdc-static/

kozzi commented on 2018-08-30 12:50 (UTC)

NEWS: gdc is now in community. Current version in community repo is based on gcc-8-stable branch so frontend id based on c++ and it is at version 2.068.2. Old aur gdc-stable package has been removed.

And gdc package from AUR has been merged into this package(gdc-git).

kozzi commented on 2018-08-16 13:29 (UTC)

Updated gdc from stable branch to new dlang frontend branch (gdc-8), previous gdc-8-stable is available as separet package: https://aur.archlinux.org/packages/gdc-stable/ which is needed to build this one.

JinShil commented on 2018-07-20 03:20 (UTC) (edited on 2018-07-20 03:23 (UTC) by JinShil)

FYI. GDC has been updated to now use the D frontend (v2.081.1). See https://github.com/D-Programming-GDC/GDC/commit/1c2972f44660d64173202a7f111bd915a578700c. This means a GDC bootstrap compiler will be needed to build GDC.

After discussing this with some of the GDC developers, they explained their strategy like this:

  • stable and gdc-x-stable branches will continue to use the C++ frontend, so they will not require a GDC bootstrap compiler.
  • master and gdc-x branches will use the D frontend, so will require a GDC bootstrap compiler

Therefore, once the D frontend gets backported to the gdc-x branches, the build procedure will be:

  1. build a bootstrap compiler from gdc-x-stable branch
  2. Use the bootstrap compiler to build gdc-x branch
  3. Perhaps use the resulting GDC compiler from (2) to build the gdc-x branch again.

This is my understanding, and I've tested this with stable and master, but be forewarned that I'm sometimes wrong. I hope this information will be helpful for others.

kozzi commented on 2018-07-12 21:23 (UTC)

Updated to the latest gdc-8-stable and to latest gcc (merge libgphobos-devel into libgphobos). For some reason I have disabled notifications, so from now on I should respond much quicker

kozzi commented on 2018-07-12 20:20 (UTC)

@FFY ok I will fix that @CyberShadow I do not build git master, and there is no usable tag, so I need to use specific branch like gdc-8 or gdc-8-stable and AFAIK gdc-git is really old and does not make sense right now

CyberShadow commented on 2018-06-24 11:11 (UTC) (edited on 2018-06-24 11:11 (UTC) by CyberShadow)

error: patch failed: libphobos/configure:14671
error: libphobos/configure: patch does not apply
error: patch failed: libphobos/m4/druntime.m4:78
error: libphobos/m4/druntime.m4: patch does not apply

Why are you building git masters in a non -git package? There already is a gdc-git. Please pick some tags and bump them at the same time as the pkgver.

FFY00 commented on 2018-06-23 18:46 (UTC) (edited on 2018-06-23 18:47 (UTC) by FFY00)

Hey, 'libgphobos-devel' should be merged with 'libgphobos'. In arch, we don't use the '-devel' suffix, that's debian. 'libgphobos' should include both the .so and development files.

Elronnd commented on 2018-03-26 17:37 (UTC)

@kozzi great! I've added you as a maintainer and stepped down.

kozzi commented on 2018-03-26 14:42 (UTC)

@Elronnd If nobody else will step forward I can continue to mantain this package

kozzi commented on 2018-03-26 14:40 (UTC)

here is updated version for latest gdc 7.3.1-date https://pastebin.com/GFxKTGnm

adsun commented on 2018-02-20 23:22 (UTC)

OK, thanks for the info. I will keep checking that pull request.

Elronnd commented on 2018-02-19 17:40 (UTC)

To the person who flagged this as out of date: 7.3.0 update incoming (takes forever to build on my machine), but the version of d-compiler is an upstream problem, pending this pull request: https://github.com/D-Programming-GDC/GDC/pull/550.

bernarcher commented on 2018-01-16 00:53 (UTC)

Just tried in a clean build. To build "libgphobos-devel" make still wants "x86_64-unknown-linux-gnu/libphobos" instead of "x86_64-pc-linux-gnu/libphobos":

==> Beginne package_libgphobos-devel()... make: *** x86_64-unknown-linux-gnu/libphobos: Datei oder Verzeichnis nicht gefunden. Schluss.

Elronnd commented on 2017-12-28 07:58 (UTC)

Oddly enough, gphobos works fine for me now. And in the Makefile, I have 'target=x86_64-pc-linux-gnu'. And cc1d is installed to /usr/lib/gcc/x86_64-pc-linux-gnu. Very curious.

bernarcher commented on 2017-12-16 03:51 (UTC)

Did still break the build trying libgphobos-devel. This was because still the "x86_64-unknown-linux-gnu" path is wanted by the makefile. This needs to be changed to "x86_64-pc-linux-gnu".

For the time being an according symlink made the build process complete.

Elronnd commented on 2017-12-11 21:47 (UTC)

Done!

CyberShadow commented on 2017-12-11 21:41 (UTC)

Could you please change the 'provides' line to indicate the frontend version (i.e. 'd-compiler=2.068.0'), like the dmd package?

Elronnd commented on 2017-09-11 05:40 (UTC)

When I compile stuff I get linker errors and have to manually link to gphobos. Not sure why.

Elronnd commented on 2017-09-11 01:20 (UTC)

Updated to gcc 7.2.0. Add a comment if anything doesn't work (it's still compiling on my system but nothing seems to be broken).

Elronnd commented on 2017-08-11 08:09 (UTC)

ben0mega, updated. Unfortunately, since .SRCINFO wasn't updated, AUR helpers won't detect that an update happened, so you'll have to either install manually or tell your aur helper to 'reinstall.'

ben0mega commented on 2017-08-04 22:48 (UTC)

This PKGBUILD doesn't respect the MAKEFLAGS from makepkg.conf (it always uses -j8, which is a problem on my system). Could you change it to use the MAKEFLAGS? It should be as simple as changing make -j 8 to make $MAKEFLAGS

Elronnd commented on 2017-07-19 04:26 (UTC)

Sorry guys! I updated the sha256 for isl 0.18, it should work now

gosella commented on 2017-07-18 17:43 (UTC)

sha256sum for isl 0.18: 6b8b0fd7f81d0a957beb3679c81bbb34ccc7568d5682844d8924424a0dadcb1b

geov commented on 2017-07-18 14:04 (UTC)

looks like you forgot to update sha256sums for new isl

commented on 2015-08-07 18:59 (UTC)

Since I no longer intend to use distributions with systemd for personal use, I will abandon this package no earlier than 2015-09-01. Should someone be interested in maintaining this package afterwards, he or she can contact me in the interim to become co-maintainer and then sole maintainer once I leave, to ensure a smooth transition.

commented on 2015-06-12 09:33 (UTC)

Initial AUR4 import.

commented on 2013-11-15 07:50 (UTC)

This sounds to me like you're getting AUR packages by hand instead of a AUR helper and only downloaded the PKGBUILD. You need the source tarball that's available on the right side directly below "View PKGBUILD" as "Download tarball". Or you could use an AUR helper like yaourt or paktahn, that so this for you.

eko commented on 2013-11-15 04:14 (UTC)

==> ERROR: folders.diff was not found in the build directory and is not a URL. how can I solve this ??

commented on 2013-10-29 11:14 (UTC)

1) the community version of this (the gdc PKGBUILD file) seperates the generated binaries/libraries into two packages, "gdc" and "libgphobox-devel" (for a discussion of why go there). Because the AUR does afaik not support split packages in a PKGBUILD, this cannot be done here. Do not try to mix gdc-git with any of these two packages, as essentially gdc+libgphobosdevel = gdc-git. 2) I could not reproduce your error in any of my attempts (which were difficult given that you did not supply a minimal working example for your problem, so I have to guess where you encounter it). I have, however, adapted the packaging function to mirror the changes made in the community PKGBUILD: Please build and install gdc-git again (preferrably after first doing "pacman -Rsunc gdc-git" to remove all traces of the previous installation) with the updated PKGBUILD I just uploaded here. If you encounter the error again, please provide a minimal working example on how to reproduce it.

soltanmm commented on 2013-10-29 03:25 (UTC)

I'm having trouble running gdc from this package; the linker reports that gphobos2 cannot be found. Running 'locate gphobos2' reveals only a static library in the AUR build directory. I cannot sync with libgphobos-devel from the Arch official packages, as this package supposedly conflicts with it according to pacman. Halp meh~! (plzthxbai, etc.)

commented on 2013-08-26 01:05 (UTC)

Added Arch integration changes done for the "gdc" package back into this package.

commented on 2013-07-24 11:04 (UTC)

Updated to gcc snapshot 4.9-20130721. Also, pkgver format from now on is {GCC_MAJOR_VERSION}.{GCC_SNAPSHOT_DATE}.{GDC_COMMIT_COUNT}.{GDC_COMMIT_HASH} to express both which gcc snapshot is used and which gdc commit was used.

commented on 2013-04-04 11:27 (UTC)

Updated to gcc snapshot 4.9-20130331, had some problems compiling with the (new) current gcc 4.8 release beforehand.

commented on 2013-03-26 11:21 (UTC)

Updated now: This will keep being compiled with GDC git master branch + GCC trunk snapshot, thus moving to GCC version 4.9.

commented on 2013-03-24 01:06 (UTC)

I'll update this once I'm relatively sure whether continuing to use the master branch (and thus implicitly switch from gcc 4.8 which was released a few days ago to the new trunk version 4.9) or switching to gdc'c new gdc-4.8 branch and thus explicitly use the gcc 4.8.x releases is the best call. For now, I'm flagging this out-of-date as it probably won't work anymore (the master branch expects gcc 4.9 not 4.8).

commented on 2013-03-11 18:15 (UTC)

Fixed now by using the latest gcc snapshot (4.8-20130310)

LeonidasXIV commented on 2013-03-11 09:58 (UTC)

Fails somewhere in package(): /tmp/yaourt-tmp-leonidas/aur-gdc-git/src/gcc-4.8-20130106/gcc/doc/service.texi:6: warning: node up `Service' in menu `Bugs' and in sectioning `Top' differ make[2]: *** [doc/gcc.info] Error 1 rm gdc.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod gcov.pod make[2]: Leaving directory `/tmp/yaourt-tmp-leonidas/aur-gdc-git/src/gcc-build/gcc' make[1]: *** [install-gcc] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-leonidas/aur-gdc-git/src/gcc-build' make: *** [install] Error 2 I could't find the actual cause because that looks like warnings and shouldn't trigger an error.

commented on 2013-01-12 19:41 (UTC)

Sorry for the delay, update brings: - (Currently) newest gcc snapshot (20130106), fixes issue reported by beatgammit - Updated gcc_pure64 patch (because a few lines were removed from t-linux64 in trunk) - Added sha256 checksums

commented on 2013-01-12 19:40 (UTC)

Sorry for the delay, update brings: - (Currently) newest gcc snapshot (20130106), fixes your issue beatgammit - Updated gcc_pure64 patch (because a few lines were removed from t-linux64 in trunk) - Added sha256 checksums

beatgammit commented on 2013-01-05 02:20 (UTC)

I get the following errors: patching file Makefile.def Hunk #1 succeeded at 128 (offset -3 lines). Hunk #2 FAILED at 499. Hunk #3 succeeded at 540 (offset -13 lines). 1 out of 3 hunks FAILED -- saving rejects to file Makefile.def.rej patching file Makefile.in Hunk #2 succeeded at 1085 (offset -2 lines). Hunk #3 succeeded at 1175 (offset -2 lines). Hunk #4 succeeded at 1258 (offset -2 lines). Hunk #5 succeeded at 1341 (offset -2 lines). Hunk #6 succeeded at 1424 (offset -2 lines). Hunk #7 succeeded at 1507 (offset -2 lines). Hunk #8 succeeded at 1590 (offset -2 lines). Hunk #9 succeeded at 1673 (offset -2 lines). Hunk #10 succeeded at 1756 (offset -2 lines). Hunk #11 succeeded at 1839 (offset -2 lines). Hunk #12 succeeded at 1922 (offset -2 lines). Hunk #13 succeeded at 2005 (offset -2 lines). Hunk #14 succeeded at 2088 (offset -2 lines). Hunk #15 succeeded at 2171 (offset -2 lines). Hunk #16 succeeded at 2309 (offset -2 lines). Hunk #17 succeeded at 2465 (offset -2 lines). Hunk #18 succeeded at 2568 (offset -2 lines). Hunk #19 succeeded at 36819 (offset -519 lines). Hunk #20 succeeded at 43310 (offset -519 lines). Hunk #21 succeeded at 45366 (offset -524 lines). Hunk #22 succeeded at 45398 (offset -524 lines). Hunk #23 FAILED at 46640. Hunk #24 succeeded at 46179 (offset -546 lines). Hunk #25 succeeded at 46215 (offset -546 lines). 1 out of 25 hunks FAILED -- saving rejects to file Makefile.in.rej I don't know too much about patch, but it seems that Makefile.def is missing this line above the inserted text (line 497): dependencies = { module=all-target-libgo; on=all-target-libatomic; }; Same deal with Makefile.in (line 46117): all-target-libgo: maybe-all-target-libatomic Can you reproduce?

commented on 2012-12-21 23:31 (UTC)

thanks for the quick response, works like a charm now. (and what a speed, resulting executable is twice as fast as dmd)

commented on 2012-12-21 14:43 (UTC)

Updated to 2012-11-18 snapshot uffuji: Could not reproduce with this (2012-11-18) snapshot, confirm?

commented on 2012-12-21 14:42 (UTC)

- Updated to 2012-11-18 snapshot uffuhi: Could not reproduce with this (2012-11-18) snapshot, confirm?

commented on 2012-12-21 12:38 (UTC)

In file included from /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-lang.cc:28:0: /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:553:3: error: 'vec' does not name a type /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h: In constructor 'CtorEltMaker::CtorEltMaker()': /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:556:7: error: class 'CtorEltMaker' does not have any field named 'head' /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h: In member function 'void CtorEltMaker::reserve(int)': /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:560:29: error: 'struct CtorEltMaker' has no member named 'head' /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:560:36: error: 'vec_safe_reserve' was not declared in this scope /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h: In member function 'void CtorEltMaker::cons(tree, tree)': /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:565:26: error: 'struct CtorEltMaker' has no member named 'head' /tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-4.8-20121111/gcc/d/d-codegen.h:565:34: error: 'vec_safe_push' was not declared in this scope make[2]: *** [d/d-lang.glue.o] Error 1 make[2]: Leaving directory `/tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-build/gcc' make[1]: *** [install-gcc] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-maarten/aur-gdc-git/src/gcc-build' make: *** [install] Error 2 What went wrong? 64-bit arch linux install

commented on 2012-11-23 22:27 (UTC)

- changed the bug url to the bugzilla site - updated to newest patchable gcc snapshot

cleger commented on 2012-11-04 17:55 (UTC)

Not likely any advantages. I just used "pc" instead of "unknown" because that was how it was set on my old pc and thought it strange that "unknown" was the new default. Changing it was probably not a good idea though (https://bbs.archlinux.org/viewtopic.php?id=112331). In other words, it was just PEBKAC.

commented on 2012-11-04 11:02 (UTC)

Ah, i see. Just curious: What's the advantage of setting $CHOST manually (I always thought one wasn't supposed to touch it since it is set automaticly)? Are there any packages that don't work with the automatic value for you?

cleger commented on 2012-11-04 05:28 (UTC)

>> What exactly did you do? I had my $CHOST set to x86_64-pc-linux-gnu in makepkg.conf. I changed it back to x86_64-unknown-linux-gnu. That worked.

commented on 2012-11-04 04:06 (UTC)

These files should be removed during packaging via the following lines at the bottom of the package-function: rm -rf $pkgdir/usr/bin/{gcc,gcov,cpp,$CHOST-gcc,$CHOST-gcc-$_gccver,c++,g++,$CHOST-c++,$CHOST-g++} rm -rf $pkgdir/usr/bin/{gcc-ar,gcc-nm,gcc-ranlib,$CHOST-gcc-ar,$CHOST-gcc-nm,$CHOST-gcc-ranlib} What exactly did you do?

commented on 2012-11-04 04:02 (UTC)

These files should be removed during packaging via the following lines at the bottom of the package-function: rm -rf $pkgdir/usr/bin/{gcc,gcov,cpp,$CHOST-gcc,$CHOST-gcc-$_gccver,c++,g++,$CHOST-c++,$CHOST-g++} rm -rf $pkgdir/usr/bin/{gcc-ar,gcc-nm,gcc-ranlib,$CHOST-gcc-ar,$CHOST-gcc-nm,$CHOST-gcc-ranlib} What exactly did you do?

cleger commented on 2012-11-04 03:56 (UTC)

File conflicts with gcc-multilib: loading packages... resolving dependencies... looking for inter-conflicts... Targets (1): gdc-git-20121104-1 Total Installed Size: 90.08 MiB Proceed with installation? [Y/n] y (1/1) checking package integrity [################################################################] 100% (1/1) loading package files [################################################################] 100% (1/1) checking for file conflicts [################################################################] 100% error: failed to commit transaction (conflicting files) gdc-git: /usr/bin/x86_64-unknown-linux-gnu-c++ exists in filesystem gdc-git: /usr/bin/x86_64-unknown-linux-gnu-g++ exists in filesystem gdc-git: /usr/bin/x86_64-unknown-linux-gnu-gcc exists in filesystem gdc-git: /usr/bin/x86_64-unknown-linux-gnu-gcc-ar exists in filesystem gdc-git: /usr/bin/x86_64-unknown-linux-gnu-gcc-nm exists in filesystem gdc-git: /usr/bin/x86_64-unknown-linux-gnu-gcc-ranlib exists in filesystem Errors occurred, no packages were upgraded.

commented on 2012-10-31 11:51 (UTC)

The source code migrated from bitbucket to github a long time ago, but issues were still to be reported at bitbucket, there was no wiki on gdcproject.org, etc., so the project home was still more bitbucket than github (even though the code was at github); recently they moved these other things over as well, but I did not want to change the url yet in case they change there minds again. But since it was more or less requested: url changed to github.

commented on 2012-10-31 08:09 (UTC)

shouldn't the web address be: https://github.com/D-Programming-GDC/GDC the project has migrated from bitbucket to github

commented on 2012-10-29 13:22 (UTC)

The -j3 shouldn't have been there, forgot to remove it after testing (it's gone now).

debio264 commented on 2012-10-28 04:44 (UTC)

Also, could you run make with ${MAKEFLAGS} instead of blindly using -j3? Building GDC on low memory systems (in my case an ARM system) will fail with -j3 because the C++ compiler will run out of memory.

commented on 2012-10-28 00:14 (UTC)

Thanks, seems like they merged the two scripts (setup-gcc.sh which was in root/gcc/d and update-gcc.sh which was in root/) and named the new one setup-gcc.sh Fixed now.

debio264 commented on 2012-10-27 23:58 (UTC)

It looks like you need to call setup-gcc.sh insetad of update-gcc.sh.

Svenstaro commented on 2012-09-17 15:37 (UTC)

Everything looks good now. Nice.

commented on 2012-09-15 20:21 (UTC)

Updated now, the problem was the missing pure64 patch that the gcc package uses (which I find quite disturbing that one needs to patch gcc to have it work correctly on a normal linux 64-bit system such as Arch). Also added cloog as a dependency because the extra-x86_64-build script says it is.

Svenstaro commented on 2012-09-10 02:41 (UTC)

You can run the command right now. It will make a clean chroot automatically. You do not need a VM.

commented on 2012-09-09 17:45 (UTC)

When I find the time to setup a new clean Archlinux VM I'll do that, hopefully that will be in the next few days. If you need a quick fix right now you could add something like mkdir -p $pkdir/usr/lib cp -a $pkgdir/usr/lib64/* $pkgdir/usr/lib/ rm -rf $pkgdir/usr/lib64 right after the make DESTDIR=$pkgdir install line. Maybe put the three lines in an if checking architecture for x86_64

Svenstaro commented on 2012-09-09 17:34 (UTC)

Try this. pacman -S devtools cd where-the-PKGBUILD-is-in sudo extra-x86_64-build This will enable you to reproduce this

commented on 2012-09-09 17:33 (UTC)

As I said I cannot reproduce that behaviour and as such cannot help debug the problem. If I find the time I'll set up another clean Arch VM with devtools and see what happens. 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.

commented on 2012-09-09 17:33 (UTC)

As I said I cannot reproduce that behaviour and as such cannot help debug the problem. If I find the time I'll set up another clean Arch VM with devtools and see what happens. 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.

commented on 2012-09-09 17:32 (UTC)

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.

commented on 2012-09-09 17:21 (UTC)

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.

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.

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

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.

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

Svenstaro commented on 2012-09-05 13:52 (UTC)

Build fails for me, even after using a more recent snapshot.

commented on 2012-08-19 10:19 (UTC)

Ibuclaw stealth-fixed the reason for the patch without commenting on it in the issue I opened, removed the patch now, should work again.

Svenstaro commented on 2012-08-19 05:13 (UTC)

Now it can't find the file to patch?

commented on 2012-08-18 18:54 (UTC)

Switched from (gcc) svn trunk to the trunk snapshots.

commented on 2012-06-25 20:55 (UTC)

Updated and added a fix for a patch issue, will be removed once the problem has been resolved in upstream.

commented on 2012-06-25 20:54 (UTC)

Updated and added a fix for a patch issue, will be removed if the problem is resolved in upstream.

commented on 2012-06-02 15:17 (UTC)

Yeah, it was, but I was waiting for the coming fix for this (https://bitbucket.org/goshawk/gdc/issue/284/lto-undefined-reference-to) issue for the next update (didn't think anyone but me was using this already). Removed the patch but included another one that fixes *most* of the linked issue (The patch - https://github.com/D-Programming-GDC/GDC/pull/15/files#L1R768 - is not made by me and is going to be merged into the trunk soon anyway, when it is, I'll remove it here).

commented on 2012-06-02 15:13 (UTC)

Yeah, it did, though there are some other fixes I was waiting for before the next update (didn't think anyone used this yet), but will update now.

commented on 2012-06-02 15:10 (UTC)

Yeah, it did, though there are some other fixes I was waiting for before the next update (didn't think anyone used this yet), but will update now.

Svenstaro commented on 2012-06-02 14:19 (UTC)

Reversed (or previously applied) patch detected! Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/d/setup-gcc.sh.rej I suppose this patch made it upstream: https://github.com/D-Programming-GDC/GDC/commit/65bcf413354769da12ccac48a287cdcf375be9a5

commented on 2012-05-28 16:09 (UTC)

Adopted and updated to build again. For that the gcc (svn) trunk is needed, because the master branch of gdc is no longer compatible to anything below gcc svn trunk revision 184805 which is already newer (BASE-VER=4.8.0) than the current latest release (gcc 4.7.0); this means that the svn trunk of gcc and the git trunk of gdc will be pulled (lay back, that is going to take a while). The patch in sources is needed because even though gdc now needs at least version 4.8.0 it has not yet been added to the version checks in setup-gcc.sh; this patch adds it.

commented on 2012-05-28 16:09 (UTC)

Adopted and updated to build again. For that the gcc (svn) trunk is needed, because the master branch of gdc is no longer compatible to anything below gcc svn trunk revision 184805 which is already newer (BASE-VER=4.8.0) than the current latest release (gcc 4.7.0); this means that the svn trunk of gcc and the git trunk of gdc will be pulled (lay back, that is going to take a while). The patch in sources is needed because even though gdc now needs at least version 4.8.0 its not yet been added to the version checks in setup-gcc.sh; this patch adds it.

commented on 2012-05-28 16:08 (UTC)

Adopted and updated to build again. For that the gcc (svn) trunk is needed, because the master branch of gdc is no longer compatible to anything below gcc svn trunk revision 184805 which is already newer (BASE-VER=4.8.0) than the current latest release (gcc 4.7.0); this means that the svn trunk of gcc and the git trunk of gdc will be pulled (lay back, that is going to take a while). The patch in sources is needed because even though gdc now needs at least version 4.8.0 its not yet been added to the version checks in setup-gcc.sh; this patch adds it.

commented on 2012-05-28 16:07 (UTC)

Adopted and updated to build again. For that the gcc (svn) trunk is needed, because the master branch of gdc is no longer compatible to anything below gcc svn trunk revision 184805 which is already newer (BASE-VER=4.8.0) than the current latest release (gcc 4.7.0); this means that the svn trunk of gcc and the git trunk of gdc will be pulled (lay back, that is going to take a while). The patch in sources is needed because even though gdc now needs at least version 4.8.0 its not yet been added to the version checks in setup-gcc.sh; this patch adds it.

demizer commented on 2012-04-04 02:59 (UTC)

I have to disown this package for school reasons. Thank you all for giving me the opportunity to maintain this package, it was a great experience!

demizer commented on 2012-04-01 18:13 (UTC)

@anta40 gdc is built using --disable-multilib, so only the 64bit version of libphobos2 is built (defined by $CARCH /etc/makepkg.conf). Try editing the PKGBUILD and changing --disable-multilib to --enable-multilib.

commented on 2012-04-01 14:40 (UTC)

Hi demizer, Many thanks. It works. Now I'm curious: is there any way to enable 32-bit compatibility? I'm using 64-bit Arch (thus, multilib gcc), so when I try something like this: gdc hello.d -o hello -m32, I get this: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../libgphobos2.a when searching for -lgphobos2 /usr/bin/ld: skipping incompatible /usr/lib/libgphobos2.a when searching for -lgphobos2 /usr/bin/ld: cannot find -lgphobos2 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status

demizer commented on 2012-03-31 10:38 (UTC)

It should be working now. One thing I noticed when building my simple programs is that you will need to pass pthread to the linker: gdc -o main test.d -pthread or gdmd test.d -L-lpthread otherwise you will get the following error: /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../lib/libgphobos2.a(monitor_.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_mutexattr_settype@@GLIBC_2.2.5' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line /lib/libpthread.so.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status This is because gcc itself (which gdc is based on) requires you to explicitly link to Dynamic Shared Objects for which pthread is used by libphobos. See https://fedoraproject.org/wiki/UnderstandingDSOLinkChange for more info.

demizer commented on 2012-03-31 02:06 (UTC)

I filed a bug report upstream: https://github.com/D-Programming-GDC/GDC/issues/10

demizer commented on 2012-03-30 15:41 (UTC)

I flagged the package out of date. The directory structure was changed upstream and I am working on a fix.

commented on 2012-03-30 14:29 (UTC)

I got this error: ==> The local files are updated. ==> GIT checkout done or server timeout ==> Starting build... patching file gcc/config/i386/linux64.h Hunk #1 succeeded at 62 with fuzz 2 (offset 13 lines). patching file gcc/config/i386/t-linux64 Hunk #1 succeeded at 25 (offset 19 lines). patching file gcc/config/alpha/linux-elf.h patching file gcc/config/i386/linux64.h patching file gcc/config/i386/linux.h patching file gcc/config/ia64/linux.h patching file gcc/config/rs6000/linux64.h patching file gcc/config/rs6000/sysv4.h patching file gcc/config/s390/linux.h patching file gcc/config/sparc/linux64.h patching file gcc/config/sparc/linux.h patching file configure patching file gcc/graphite-clast-to-gimple.c /home/anta40/gdc-git/PKGBUILD: line 67: ./gcc/d/setup-gcc.sh: No such file or directory ==> ERROR: A failure occurred in build(). Aborting...

demizer commented on 2012-03-26 02:32 (UTC)

Update: Fixed building in the correct directory. Fixed variable declaration syntax.

demizer commented on 2012-03-26 01:20 (UTC)

Compilation error has now been fixed upstream.

demizer commented on 2012-03-25 18:12 (UTC)

I posted a new bug report upstream here: https://github.com/D-Programming-GDC/GDC/issues/7

Svenstaro commented on 2012-03-25 17:10 (UTC)

Currently doesn't compile.

demizer commented on 2012-03-23 04:45 (UTC)

gdc doesn't support dmd 2.058 yet, pretty sure not gcc 4.7. I have updated gcc to 4.6.3.

Svenstaro commented on 2012-03-23 03:32 (UTC)

Can't this use gcc 4.6.3? Perhaps 4.7.0 even?