This is an ebuild for the D frontend for GCC and it's runtime lib.
Created attachment 29497 [details] Phobos-0.0.1_rc5.ebuild (New Package) gdc runtime - library
Created attachment 29498 [details] gdc-0.0.1_rc5.ebuild (New Package) gdc compiler frontend
I would suggest dev-lang for both packages.
A reporter will get email - no need to cc.
George of the lang-misc heard this is yours. You can set an email address on emu:/var/mail/alias/misc.
I'd like to see this added as well! I sincerely hope D will be a worthy successor to the C throne.
I also would like to see gentoo on portage: D seems to be a better sucesor of C than C++, Objetive C or Java.
Do we have the ability to use Bugzilla's voting mechanism or will the CC list suffice?
there's a new version at http://home.earthlink.net/~dvdfrdmn/d i've ported the ebuilds and it doesn't make much sense to me, that there are two ebuilds. one for the compiler and one for the runtime library so i've made one of them.this is especially useful as the new Phobos version needs boehm-gc which is in the gcc tarball this ebuild is a bloody hack and works only with gcc 3.4, maybe someone with more free time can clean it up... otherwise i'll do that later
Created attachment 30789 [details] gdc-0.0.1_rc6.ebuild
Created attachment 30888 [details] Latest version of GDC and improved ebuild I've used the used the ebuild submitted by Sebastian. There still were some hardcoded compiler versions I've changed. The ebuild now tries to guess the patch it should use. The object files are now deleted before copying into the include dir. The libphobos.spec file is installed. I've changed the versioning system. The ebuild's name now corresponds to the dmd version used.
your new ebuild has a bug: you should test for 3.4.0 not 3.4 for the patch also i think now the seperation of gdc and phobos was a good idea as for example perl and libperl a seperated, too i've seperated the ebuilds again and added phobos as PDEPEND in the gdc ebuild works for gcc 3.3.2, 3.3.3 and 3.4.0
Created attachment 30912 [details] gdc-0.8.2-r6.ebuild without phobos but PDEPEND on phobos
Created attachment 30913 [details] phobos-0.8.2-r6.ebuild only phobos but with a bug (which is also in the combined ebuild) phobos somehow must be linked to boehm-gc when compiling a D program but it shouldn't... maybe we should add a DEPEND to boehm-gc but I think it's better to fix this bug somehow
Created attachment 30914 [details] phobos-0.8.2-r6.ebuild the DEPEND to gdc was wrong, fixed... it's too early in the morning ;)
On AMD64 it installs cc1d into this strange directory: "/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3:/usr/lib/gcc-lib/x86_64-pc-linux- gnu/3.3.3/32:/usr/lib/gcc-lib/x86_64-pc-linux-gnu/lib64:/usr/lib/gcc-lib/x86_64- pc-linux-gnu/lib32/cc1d" (yes, that is a single directorytree with directorynames containing ":")
Created attachment 35313 [details] dev-lang/gdc/gdc-0.8.2-r7.ebuild Updated to 20040427-patch.
Created attachment 35314 [details] dev-libs/phobos/phobos-0.8.2-r7.ebuild Updated to 20040427-patch.
New release: http://home.earthlink.net/~dvdfrdmn/d/
Created attachment 43022 [details] New ebuild for gdc Gdc is now on par with dmd compiler version 0.102
Created attachment 43023 [details] New ebuild for phobos
What does it take for a package such as GDC to be included in portage? It's now over 8 months since the initial bug report and AFAICS nothing has happened. Is it a quality of ebuild issue? Must the package be stable? Must someone volunteer to be mantainer? GDC 0.9 and Phobos 0.109 seems to have installed perfectly on my system (changing only the version numbers in the ebuilds above).
Created attachment 47240 [details] GDC 0.9 ebuild This is an ebuild for the 0.9 release of gdc.
Created attachment 47241 [details] Ebuild for phobos in gdc-0.9 New version on GDC phobos
Created attachment 47242 [details] Fix typo in gdc-0.9 ebuild above. Sheisse. Stupid typo... mumble.. grumble...
Created attachment 48200 [details] gdc 0.10 ebuild
Created attachment 48201 [details] phobos 0.10 ebuild
would love to see this as a new package with gcc.
Maybe we should change the gcc packages to include gdc. There could be a new gdc useflag?
The interesting part is that cygwin already has a package called gdc which one can install as part of the gcc ebuild. We (gentoo) should also have the same. I love gentoo and it's just makes sense.
It only depends if GDC is part of the real GCC yet. :-) For instance, GJC is part of the real GCC, so it's a USE flag. But if GDC isn't, it will naturally remain as a separate package.
A separate package is ok as long as one could emerge it. ie. emerge gdc
Ok, I just installed the latest ebuilds... 0.10 and I cannot get gdc working properly with them. First I had to modify the gdc ebuild to say: if [ "${GCC_PV}" > "3.4.0" ] Then, of course, I also had to add unset LDFLAGS to the phobos ebuild (cause I have LDFLAGS set) Everything compiles cleanly and installs fine, but when I try and use gdc on test.d, everything gets weird. (test.d is just a standard hello world type program that I know works) # gdc test.d /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libphobos.a(d_os_dep.o)(.text+0x61c): In function `GC_write_fault_handler': [SNIP] /var/tmp/portage/phobos-0.10/work/gcc-3.4.3/gcc/d/phobos/boehm-gc/d_os_dep.c:1990: undefined reference to `GC_push_all_stacks' collect2: ld returned 1 exit status It's obvious that boehm-gc isn't being compiled in to libphobos.a. When I enable the CFLAGS, then it dies trying to compile boehm-gc. Is this an upstream problem? I did get it working though... This is what I have to do: # emerge -u boehm-gc then when compiling, use # gdc test.d -lgc That seems to work. Obviously bohem garbage collector isn't being compiled in. For now, that will work :) ANNNDDD I guess I have the latest and greatest gc as well :)
also, because my gcc was something like 3.4.3-20050110, both ebuilds did not extract the correct gcc tar.bz2 file... The following is the line that should be changed: from: GCC_PV=$(gcc -dumpversion) to: GCC_PV=$(gcc -dumpversion | sed -e 's/-.*//') of course it complains about gcc and sed being in global scope now, but I have no idea what that means or how to fix it.
I updated my system earlier today, which produced new bugs... Anyway, my last message didn't totally solve the problem. It wasn't until I tried compiling my project with gdc that I found out that could not find libphobos.spec because gdc had the version of "3.4.3" while gcc had the version of "3.4.3-20050110" -- this meant that phobos was installing itself to the gcc version, and gdc was looking in a directory that didn't exist. The following needs to be changed to the gdc ebuild (among the others above I posted) change: GCC_PV=$(gcc -dumpversion) to: GCC_PV=$(gcc -dumpversion | sed -e 's/-.*//') GCC_PVF=$(gcc -dumpversion) GCC_LIBS="`gcc-config --get-lib-path`" # GCC_LIBS must be saved before we inherit toolchain # toolchain makes gcc-config not work # toolchain is used to patch the version inherit toolchain find: cd "${S}/gcc" add to next line: gcc_version_patch "${GCC_PVF}" ----------------- Sorry for posting so many times! I try and consolidate as much as possible, but bugs pop up as I keep playing with the system :) ----------------- also, if there are others that are getting errors about phobos having undefined references to GC_... functions, just add to the libphobos.spec "-lgc" and make sure boehm-gc is emerged. or you can append this to the end of the src_install, before it cp libphobos.spec if [[ -nz "`nm /usr/lib/libphobos.a | grep 'U GC_base'`" ]] ; then eerror eerror "Phobos does not have a garbage collector!"; eerror "when you try and compile a project it will" eerror "give you errors about undefined GC symbols" eerror "Please emerge boehm-gc" eerror " emerge boehm-gc" ewarn ewarn "patching libphobos.spec for use with boehm-gc" sed -i -e 's/%(liborig)/%(liborig) -lgc/' libphobos.spec ewarn fi
"phobos" ebuild in this package conflicts with "dmd" (Bug 46806) My suggestion is to included all of Phobos into the GDC package, until D stabilizes somewhat (1.0?) and comes out with a portable runtime library... (as the current Phobos is most definitely not)
Created attachment 51936 [details] dev-lang/gdc/gdc-0.10.ebuild Fixed the versions of GCC and GDC, to not shell out and not hardcode... Also fixed the wrong ebuild header, and added error checks to patching.
Not that the new ebuild built correctly, or anything... install: `/var/tmp/portage/gdc-0.10/work/gcc-3.4.3/gcc/d/dmd' is a directory ./usr/bin/gdc ./[1] i686-pc-linux-gnu-3.4.3-20050110\n[2] i686-pc-linux-gnu-3.4.3-20050110-hardened\n[3] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie\n[4] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp/ ./[1] i686-pc-linux-gnu-3.4.3-20050110\n[2] i686-pc-linux-gnu-3.4.3-20050110-hardened\n[3] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie\n[4] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp/cc1d But it should be on the right way.. :-)
wow, do I feel stupid! I forgot to tell you another change. The lines in the install should read: dodir "${GCC_LIBS}" cp ${S}/gcc/cc1d ${D}"${GCC_LIBS}" I'm going to try a compile real quick. I'm not sure that gcc-major-version will work though :)
Created attachment 51962 [details] hopefully fixes the gcc version problems discussed below
Created attachment 51963 [details] fixes the issues with boehm-gc and linking
Created attachment 52156 [details] dev-lang/gdc/gdc-0.10.ebuild This new ebuild replaces both old ebuilds (i.e. it now has Phobos included as well) Other changes: - conflict added with DMD, to RDEPEND - strips CFLAGS, just like the gcc ebuild - now builds objects outside the source dirs - added the Phobos unittest to src_test - removed C code from the includes - not adding "internal" to the package Known bugs: (these are upstream problems) - the unittest fails Error: AssertError Failure /var/tmp/portage/gdc-0.10/work/gcc-3.4.3/gcc/d/phobos/std/format.d(734) - the manpages are missing
Created attachment 52174 [details] dev-lang/gdc-0.10-r2.ebuild A small fix of the merged gdc/phobos ebuild: LDFLAGS has to be unset before building phobos, to avoid problems with boehm-gc.
Comment on attachment 52174 [details] dev-lang/gdc-0.10-r2.ebuild unsets LDFLAGS before phobos is built, to avoid problems with boehm-gc's(caused by the configure script).
Created attachment 54128 [details] gdc-0.10-r3.ebuild Changed DEPEND="virtual/glibc and RDEPEND="virtual/glibc to DEPEND="virtual/libc RDEPEND="virtual/libc
Created attachment 57865 [details] dev-lang/gdc/gdc-0.11.ebuild - Cleaned up the patching + added new toplev - Cleaned up the installation (make install now) - Added ~PPC ("signed char" should be fixed now) - No longer needs gcc-java package to build - Removed src_test, but it should work OK I think - Manpages are now included in the upstream tarball
When using the 0.11 ebuild to compile 0.12 and 0.13 it crashed with an error when it came to recls because it configured it with only --enable-languages=d. I changed this to --enable-languages=c,c++,d as suggested by the gdc INSTALL file, and this worked. I have tested it with dstress and it works just fine. Which brings me to point #2. __Why__ isn't this ebuild in portage? This is a working ebuild for working GPLed software.
Created attachment 61300 [details] dev-lang/gdc/gdc-0.13.ebuild New ebuild for gdc-0.13 (also works for gdc-0.12).
I agree with sigbjorn. Why isn't this in portage? I am waiting until the day that I could say, emerge gdc or emerge phobos without having to edit or add anything to the portage system. Com'on! Even cygwin has gdc as part of their setup download! Gentoo should get with it. :-) thanks, jos
I agree with sigbjorn. Why isn't this in portage? I am waiting until the day that I could say, emerge gdc or emerge phobos without having to edit or add anything to the portage system. Com'on! Even cygwin has gdc as part of their setup download! Gentoo should get with it. :-) thanks, josé It's been a while now. We should push Gentoo folks to make it as part of their normal
agreed. Why isn't this in portage. Or probably the better question: is the mere existence of this bug enough to get the gentoo dev attention, and put it in portage one day or another, or is there a better way to notify the devs that this ebuild is fine now, at least for ~arch. maybe changing its status to test-request would get things moving. I don't know, I am no expert of bugzilla, and gentoo's use of it.
I went to ask in #gentoo-bugs (I'm Pkunkage): Pkunkage - There's an ebuild bug that I'm wondering if has been orphaned... The ebuild is stable, but there's been no word on anyone who can put it into portage. Can any of you help? (or is this the wrong channel?) bonsaikitten - Pkunkage, getting a dev to take care of an ebuild is never easy Pkunkage - They don't need to take care of it Pkunkage - We (the users of the software) will do that Pkunkage - But it'd be nice if it was in Portage, that's all bonsaikitten - heh bonsaikitten - so who's going to fix bugs? ;-) Pkunkage - bonsaikitten, it's a compiler (dev-lang/gdc). I suspect the users of that software will be quite capable of fixing bugs that come up. All we'd like is that it's finally committed to portage after over a year of waiting. bonsaikitten - Pkunkage, no, who's going to fix a broken ebuild? bonsaikitten - problem is, if noone takes care of it you won't be happy kloeri - Pkunkage: some developer still has to take responsibility for the ebuild - we can't just add ebuilds to portage and wave our hands around in the air when bugs shows up kloeri - Pkunkage: many devs (including myself) are quite hesitant to do that as we're already quite busy with other ebuilds Pkunkage - Right. What has to be done, then? Do I need to headhunt an existing developer, try to become a developer, lick somebody's toes? Pkunkage - bonsaikitten, the same ones who've fixed the ebuild a number of times over the last year, whenever it hasn't worked. (http://bugs.gentoo.org/show_bug.cgi?id=48136 btw) GenBot - Pkunkage: Bug 48136; "gdc-0.0.1_rc5.ebuild (New Package) phobos-0.0.1_rc5.ebuild (New Package)"; [Gentoo Linux :: Ebuilds]; {NEW}; Stephan Wienczny->George Shapovalov bonsaikitten - Pkunkage, can they commit to gentoo cvs? bonsaikitten - if no, it doesn't really matter bonsaikitten - and, of course, portage supports overlays ... jakub - Pkunkage: well, honestly - seems like a non-trivial thing really, so this needs someone who's gonna have time to fix the bugs if they come Pkunkage - bonsaikitten, no we can't. I'd have imagined that if someone couldn't commit it themselves then maybe they could submit it to somebody who *could* Pkunkage - We've used overlays for over a year as it is Pkunkage - We'd like, however, the convenience of portage, plus making it more readily available for others Pkunkage - jakub, do I have to find some existing dev or can one of the people who've been working on the ebuild so far do the job? kloeri - Pkunkage: you need to either find a developer who's willing to take on your package or find a developer willing to mentor you and take you on as a new developer Pkunkage - right Pkunkage - ty jakub - also, this being a gcc frontend might cause other things to break... I've seen one really strange bug with cologcc, IIRC Pkunkage - Well Pkunkage - No use in crying over milk before it's been spilt. Any takers? (If nobody wants to I will attempt, but I thought it'd be courteous to ask. I'm probably one of the less experienced programmers here anyway.)
Re-assign.
Created attachment 75655 [details] dev-lang/gdc-0.17.ebuild Updated ebuild for gdc-0.17. Changes to 0.13: - "inherit toolchain" removed: I think the semantics of the toolchain eclass have changed. - 'rebranding' is now done directly with sed (that was the only functionality of the toolchain eclass that was used). - changed --enable-languages=c,d,c++ to just --enable-languages=d,c++: still works. I'm no ebuild expert, but it works for me.
While the most recent ebuild (dev-lang/gdc-0.17.ebuild) successfully builds and installs for me, I am having some problem actually using the gdmd binary. >>start-paste<< trevor@zeppelin ~ $ gdmd test.d gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ cat test.d import std.stdio; alias char[] string; int main (string[] argv) { foreach (string s; argv) { writefln("%s", s); } return 0; } >>end-paste<< As you can see I appear to be missing `ccld'. I did a `emerge -s ccld' with no luck. Any suggestions? P.S. I can compile test.d with the official D compiler shipped by Digital Mars (dmd).
The name of that executable is actually "cc1d" (the third character is a digit). It's a part of GDC and should have been installed by the ebuild. Please run $ gdmd -v test.d and it will tell you in the first few lines which cc1d binary it tries to use. For example, it's /usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1d in my case. What is your GCC version? Please also find out if the ebuild has installed any file named cc1d at all: Just emerge app-portage/gentoolkit and run $ equery files =dev-lang/gdc-0.17 to see the contents of the package.
trevor@zeppelin ~ $ gdmd -v test.d Using built-in specs. Configured with: /var/tmp/portage/gdc-0.17/work/gcc-3.4.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-languages=c++,d Thread model: posix gcc version 3.4.4 (gdc 0.17, using dmd 0.140, Gentoo 0.17) cc1d test.d -quiet -dumpbase test.d -mtune=pentiumpro -auxbase-strip test.o -version -o /tmp/ccaT0cQh.s gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ equery files =dev-lang/gdc-0.17 | grep cc1d /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/cc1d I have gcc-3.4.4-r1 installed. I think the problem is that gdmd is just calling cc1d and not giving the full path explicitly, but I do not know how to fix this.
Sorry, I can't reproduce the problem. Does 'gdc' work? What is the output of gdc -print-search-dirs? gcc (or gdc, in this case) uses those paths to search for the cc1d binary. As a work-around you could try to set GCC_EXEC_PREFIX (temporarily) to /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/.
I didn't even realize there was a 'gdc'. What is the difference between 'gdc' and 'gdmd'? Anyways, neither works with or without $GCC_EXEC_PREFIX set. >>start-paste<< trevor@zeppelin ~ $ echo $GCC_EXEC_PREFIX trevor@zeppelin ~ $ gdc test.d gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ gdmd test.d gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ gdc -print-search-dirs install: /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/ programs: =/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/:/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/../../i686-pc-linux-gnu/bin/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/../../i686-pc-linux-gnu/bin/ libraries: =/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/../i686-pc-linux-gnu/3.4.4/:/usr/lib/gcc/../:/lib/i686-pc-linux-gnu/3.4.4/:/lib/:/usr/lib/i686-pc-linux-gnu/3.4.4/:/usr/lib/ trevor@zeppelin ~ $ gdc test.d gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ GCC_EXEC_PREFIX="/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/" trevor@zeppelin ~ $ echo $GCC_EXEC_PREFIX /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/ trevor@zeppelin ~ $ gdc test.d gdc: installation problem, cannot exec `cc1d': No such file or directory trevor@zeppelin ~ $ gdmd test.d gdc: installation problem, cannot exec `cc1d': No such file or directory >>end-paste<<
Created attachment 76443 [details] dev-lang/gdc-0.17-r1 - Removed the block when DMD is installed. There are no conflicts anymore since GDC now uses libgphobos instead of libphobos for the runtime library and gdmd instead of dmd for the dmd wrapper script. - Use econf instead of calling ./configure directly. This sets the CHOST correctly and *may* fix the problem Trevor has seen.
Wow, so much activity with D! Sorry about gdc and dmd sitting for so long in bugzilla, but it is really an issue with maintainership. I *may* get to it at some point (I seem to be the only one who cares about "ezotheric" stuff, that I can see, unfortunately), however this will not happen for another few month realistically - I am now mentoring a new dev to take care of prolog interpreters/compilers we *already* have and I am in the middle of reorganizing Ada compilers. And this is after my low activity period, - things are picking up, but I cannot do much singlehandedly.. Still, I mush have somebody to take care of this language after the initial work is done and it is added. That means somebody will have to take up on the responsibility to take care of this package, the dmd compiler and other related stuff (and we will create a new herd for that). I will try to post to -dev to see if toolchain people would be willing to look into this (this is a successor to C after all), but don't hold your breath.. I am ressigning this to lang-misc for now, we'll see how it goes. Few technical remarks: 1. Is this right that now gdp, phobos and dmd do not have any common files? If yes, then there is no need to do complicated stuff like installing them in $PN-marked locations and using some selector tool. So this simplifies things a bit. 2. Still, as I understand the backends are gonna change, for gdc at least, as this follows gcc. Therefore it makes sense to SLOT it/them. Since the rts is split off of gdc this may not be so trivial. What is the situation with dmd? What backend does it use? How often is it going to change? 3. Correspondingly, if SLOTting is done, an eselect module will have to be produced to manage active versions. 4. Are there any language-specific libraries that people would want added to portage as well? They will have to deal with installed versions as well and some update or, at least, new-compiler-version notification mechanism will have to be implemented to deal with future upgrades.. So, as you see there is yet some work before this thing can be considered "clear" for inclusion. I can give some guidance on parts of the process, (you can try tracking #111340 for examples of eclass and ebuilds for Ada compilers with SLOTting and common backends, or you can go straight for toolchain.eclass) but I cannot do all of it myself. Not realistically at least, especially since I have no personal interest in the language. And, there must be a long term maintainer (or a proposition of one), before I will even consider going deeper into gdc/dmd packages. George
I have created a new bug (#118209) to keep track of all the D related packages that are in or will be added to bugzilla. I marked this bug and #46806 (dmd) as its dependencies. Please add other ones that you know of. I also added some of the more active people of this bug the new bug CC (so that somebody actually tracks stuff even if I will not pick this up), if you feel like it, you may add yourself there too.. George
(In reply to comment #60) > 1. Is this right that now gdp, phobos and dmd do not have any common files? If > yes, then there is no need to do complicated stuff like installing them in > $PN-marked locations and using some selector tool. So this simplifies things a > bit. Yes > 2. Still, as I understand the backends are gonna change, for gdc at least, as > this follows gcc. Therefore it makes sense to SLOT it/them. Since the rts is > split off of gdc this may not be so trivial. > What is the situation with dmd? What backend does it use? How often is it going > to change? The backend of DMD(partly based on DMC) is very unlikely to change any time soon. > 4. Are there any language-specific libraries that people would want added to > portage as well? They will have to deal with installed versions as well and > some update or, at least, new-compiler-version notification mechanism will have > to be implemented to deal with future upgrades.. Personally I'd like to see the C bindings(allowing access of libs with C interfaces from D) somehow organized. This'll require some coordination in the D community and isn't yet ready for an ebuild.
Alternatively, I've made a small modification to toolchain.eclass to give gcc a 'dlang' USE flag. It already has 'java' and 'fortran'... This approach lets you switch between multiple D enabled GCCs with gcc-config. It's working for me with gcc 3.4.5-r1 and 4.0.2-r3. I'll attach the diff. Maybe this way no new ebuilds or maintainers would be required?
Created attachment 82069 [details, diff] Diff to portage/eclass/toolchain.eclass
I've tested the ebuild in comment #59 and seems to work fine.
I have done some work on toolchain.eclass and have some interest in the language itself. A peer of mine is not a Gentoo dev but is very interested in D and might be interested in maintaining the package by proxy. I'll talk to him tomorrow. Stinks that this has gone a long time without attention. However, this sort of thing has the potential to be very "high maintenance" because toolchains touch and are affected by lots of parts of the system.
(In reply to comment #66) > I have done some work on toolchain.eclass and have some interest in the > language itself. A peer of mine is not a Gentoo dev but is very interested in D > and might be interested in maintaining the package by proxy. I'll talk to him > tomorrow. Nice. If there is a significant interest on his part, I could mentor him, or may be you can (possibly not right away - first I need to see what else has he done. Did he do any other submissions to the bugzilla or elsewhere?) > Stinks that this has gone a long time without attention. Yea, but we need somebody to step-up and maintain this thing, long term.. > However, this sort of > thing has the potential to be very "high maintenance" because toolchains touch > and are affected by lots of parts of the system. I am not sure what you mean by this. You will most definitely *not* use toolchain.eclass itself, as it assumes quite a bit about working on gcc directly. At some point when reorganizing gnat ebuilds I spoke about this on irc with toolchain people and I was discoraged from even inheriting toolchan.eclass. Instead I was told to copy parts of it as necessary to my own. This was about January this year.. By now, the gnat-xxx compilers are organized and work well (and are in ~arch already). The maintenance involved when new versions come out has been pretty low so far. You (or whoever will maintain gdc) should definitely take a look at gnatbuild.eclass - it does SLOTs, multiple related packages (gnat-gcc and gnat-gpl at the moment), multilib and preparation of the environment for every profile. It may (quite likely in fact) be pretty easy to adapt it to gdc. I would be interested to see how similar it turns out to gnatbuild.eclass (note: gnat.eclass is for the libs. I attempt to do some "fancy" things there but it is not completely finished yet). If it (the gdc.eclass, or whatever it is called) turns out to be very similar to gnatbuild.eclass we may look into merging them into some gcc-frontend.eclass, to have some common ground for all frontends that are out there. But first we need of course to see if that makes any sense.. While I am on it I should mention, that after I am done with Ada (the compilers are done, its the libs at the moment) I will be looking to move gpc (Pascal) to the same rails. So I will be touching this question of a common eclass anyway soon. George
Created attachment 88411 [details] dev-lang/gdc-0.18 Guys, I am an idiot... I'm running a gcc-4.1.1 system now, and I went to upgrade to the latest gdc, so I made the ebuild for 0.18, and then when I got everything working (using the sourceforge instead) it failed on gcc 4.1 unsupported, so this ebuild is 100% untested. If it doesn't work, it should only need a very little bit to get it working... peace
got the ebuild gdc-0.19 working 1) had only gcc-4.1.1 installed 2) then installed gcc-3.4.6 3) gcc-config i686-pc-linux-gnu-3.4.6 4) then copied gdc-0.18.ebuild to gdc-0.19.ebuild 5) then added GCC_PVS="3.4.6" before DESCRIPTION (and after GCC_LIBS) (so I forced it, needed to do it because the emerge would fail on gcc-4.1.1) 6) gcc-config i686-pc-linux-gnu-3.4.6 bye, rm
I'm sorry, last step should be 6) gcc-config i686-pc-linux-gnu-4.1.1 to restore the original gcc bye roel
Created attachment 101166 [details] dev-lang/gdc-0.19 This is dev-lang/gdc-018.ebuild with two very minor changes. The source tarball name pattern has changed, causing the download to fail.
just update for 'hardcore' gentoo users: 1) _first_ # emerge -av =sys-devel/gcc-3.4.6-r2 and switch to # gcc-config i686-pc-linux-gnu-3.4.6 2) _then_ rename ebuild #72 to gdc-0.21.ebuild and run # ebuild gdc-0.21.ebuild digest 3) # emerge -av gdc # gcc-config i686-pc-linux-gnu-4.1.1 ---- /usr/include/d/3.4.6/* /usr/lib/libgphobos.a /usr/lib/libgphobos.spec /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/cc1d /usr/bin/gdc (D font end) /usr/bin/gdmd (perl wrapper - dmd emulation) (dmd.1.003.zip) # cd dmd/samples/d # gdmd pi.d # ldd pi linux-gate.so.1 => (0xb7f93000) libm.so.6 => /lib/libm.so.6 (0xb7f42000) !! libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0xb7f37000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f20000) libc.so.6 => /lib/libc.so.6 (0xb7df8000) /lib/ld-linux.so.2 (0xb7f94000) # ./pi 2000 3 seconds to compute pi with a precision of 2000 digits.
Created attachment 109352 [details] dev-lang/gdc-0.22.ebuild gdc-0.22 released with support for gcc-4.1. removed the failure on gcc-4.1 and bumped the version to 0.22 compiles for me. MUCH THANKS!!
GDC 0.23 is out. 64-bit support was added. Simply renaming the 0.22 ebuild to 0.23 doesn't work on my amd64 system; it dies while building the multilib version. checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-lang/gdc-0.23/work/gdc-build' make: *** [all] Error 2 !!! ERROR: dev-lang/gdc-0.23 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 3286: Called src_compile gdc-0.23.ebuild, line 81: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/dev-lang/gdc-0.23/temp/build.log'. !!! This ebuild is from an overlay: '/home/alaran/src/overlay'
There's no need for a new ebuild. gcc-4.1.2 can be compiled to support D, see bug #159196. We're working on bringing the option into the tree soon, but that won't happen until the internal compiler error is solved. We'll revisit the bug later, if required.
$ USE="d" emerge gcc should do the trick. Closing bug.
Created attachment 124766 [details] Tarball for gdc-0.23 ebuild Tarball for gdc-0.23 ebuild including digest files. How to get this into sunfire?
This bug is to be closed, as GDC 0.23 is already available in the tree with GCC 3.4.6 and 4.1.2. See comments above.
...and really closing.
Tarball for gdc-0.23 ebuild by Sjoerd van Leent does not work on paludis 0.24.6. Paludis says "global scope cut" and so gcc-version, and other gcc-info eclass functions don't work returning empty strings.
