Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 48136 - gdc-013 (New Package) phobos-0.8.2 (New Package)
Summary: gdc-013 (New Package) phobos-0.8.2 (New Package)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Maintainers for Miscelleneous Language Packages [OBSOLETE]
URL: http://digitalmars.com/d
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks: 118209
  Show dependency tree
 
Reported: 2004-04-17 09:19 UTC by Stephan Wienczny
Modified: 2007-11-29 02:32 UTC (History)
37 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Phobos-0.0.1_rc5.ebuild (New Package) (phobos-0.0.1_rc5.ebuild,727 bytes, text/plain)
2004-04-17 09:20 UTC, Stephan Wienczny
Details
gdc-0.0.1_rc5.ebuild (New Package) (gdc-0.0.1_rc5.ebuild,2.22 KB, text/plain)
2004-04-17 09:21 UTC, Stephan Wienczny
Details
gdc-0.0.1_rc6.ebuild (gdc-0.0.1_rc6.ebuild,2.64 KB, text/plain)
2004-05-05 11:15 UTC, Sebastian Dröge
Details
Latest version of GDC and improved ebuild (gdc-0.8.2-r6.ebuild,2.97 KB, text/plain)
2004-05-06 18:58 UTC, Stephan Wienczny
Details
gdc-0.8.2-r6.ebuild (gdc-0.8.2-r6.ebuild,1.18 KB, text/plain)
2004-05-07 02:21 UTC, Sebastian Dröge
Details
phobos-0.8.2-r6.ebuild (phobos-0.8.2-r6.ebuild,1.13 KB, text/plain)
2004-05-07 02:23 UTC, Sebastian Dröge
Details
phobos-0.8.2-r6.ebuild (phobos-0.8.2-r6.ebuild,1.13 KB, text/plain)
2004-05-07 02:28 UTC, Sebastian Dröge
Details
dev-lang/gdc/gdc-0.8.2-r7.ebuild (gdc-0.8.2-r7.ebuild,1.28 KB, text/plain)
2004-07-13 06:54 UTC, Per Wigren
Details
dev-libs/phobos/phobos-0.8.2-r7.ebuild (phobos-0.8.2-r7.ebuild,1.24 KB, text/plain)
2004-07-13 06:55 UTC, Per Wigren
Details
New ebuild for gdc (gdc-0.102.ebuild,1.20 KB, text/plain)
2004-10-31 09:55 UTC, Anders Runesson
Details
New ebuild for phobos (phobos-0.102.ebuild,1.14 KB, text/plain)
2004-10-31 09:57 UTC, Anders Runesson
Details
GDC 0.9 ebuild (gdc-0.9.ebuild,1.26 KB, text/plain)
2004-12-30 14:10 UTC, Anders Runesson
Details
Ebuild for phobos in gdc-0.9 (phobos-0.9.ebuild,1.14 KB, text/plain)
2004-12-30 14:14 UTC, Anders Runesson
Details
Fix typo in gdc-0.9 ebuild above. (gdc-0.9.ebuild,1.26 KB, text/plain)
2004-12-30 14:34 UTC, Anders Runesson
Details
gdc 0.10 ebuild (gdc-0.10.ebuild,1.27 KB, text/plain)
2005-01-11 06:14 UTC, Anders Runesson
Details
phobos 0.10 ebuild (phobos-0.10.ebuild,1.14 KB, text/plain)
2005-01-11 06:14 UTC, Anders Runesson
Details
dev-lang/gdc/gdc-0.10.ebuild (gdc-0.10.ebuild,1.69 KB, text/plain)
2005-02-23 05:11 UTC, Anders F Björklund
Details
hopefully fixes the gcc version problems discussed below (gdc-0.10-r1.ebuild,1.76 KB, text/plain)
2005-02-23 10:10 UTC, Anders Runesson
Details
fixes the issues with boehm-gc and linking (phobos-0.10-r1.ebuild,1.69 KB, text/plain)
2005-02-23 10:14 UTC, Anders Runesson
Details
dev-lang/gdc/gdc-0.10.ebuild (gdc-0.10.ebuild,3.47 KB, text/plain)
2005-02-25 14:35 UTC, Anders F Björklund
Details
dev-lang/gdc-0.10-r2.ebuild (gdc-0.10-r2.ebuild,3.50 KB, text/plain)
2005-02-26 03:33 UTC, Anders Runesson
Details
gdc-0.10-r3.ebuild (gdc-0.10-r3.ebuild,3.49 KB, application/octet-stream)
2005-03-21 21:27 UTC, Nathan Evans
Details
dev-lang/gdc/gdc-0.11.ebuild (gdc-0.11.ebuild,2.59 KB, text/plain)
2005-05-02 12:36 UTC, Anders F Björklund
Details
dev-lang/gdc/gdc-0.13.ebuild (gdc-0.13.ebuild,2.60 KB, text/plain)
2005-06-15 13:26 UTC, Sigbjørn Lund Olsen
Details
dev-lang/gdc-0.17.ebuild (gdc-0.17.ebuild,2.84 KB, text/plain)
2005-12-27 17:54 UTC, Marcel Martin
Details
dev-lang/gdc-0.17-r1 (gdc-0.17-r1.ebuild,2.82 KB, text/plain)
2006-01-07 05:24 UTC, Marcel Martin
Details
Diff to portage/eclass/toolchain.eclass (toolchain.eclass.diff,2.22 KB, patch)
2006-03-13 22:14 UTC, Sterling Christensen
Details | Diff
dev-lang/gdc-0.18 (gdc-0.18.ebuild,2.80 KB, text/plain)
2006-06-05 02:18 UTC, Kenny Bentley
Details
dev-lang/gdc-0.19 (gdc-0.19.ebuild,2.81 KB, text/plain)
2006-11-03 13:33 UTC, Jose Quinteiro
Details
dev-lang/gdc-0.22.ebuild (gdc-0.22.ebuild,2.83 KB, text/plain)
2007-02-06 17:22 UTC, Kenny Bentley
Details
Tarball for gdc-0.23 ebuild (gdc-0.23-with-digest.tar.gz,2.23 KB, application/x-gzip)
2007-07-13 20:04 UTC, Sjoerd van Leent
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Wienczny 2004-04-17 09:19:16 UTC
This is an ebuild for the D frontend for GCC and it's runtime lib.
Comment 1 Stephan Wienczny 2004-04-17 09:20:29 UTC
Created attachment 29497 [details]
Phobos-0.0.1_rc5.ebuild (New Package)

gdc runtime - library
Comment 2 Stephan Wienczny 2004-04-17 09:21:28 UTC
Created attachment 29498 [details]
gdc-0.0.1_rc5.ebuild (New Package)

gdc compiler frontend
Comment 3 Stephan Wienczny 2004-04-17 09:23:14 UTC
I would suggest dev-lang for both packages.
Comment 4 Daniel Black (RETIRED) gentoo-dev 2004-04-17 19:12:44 UTC
A reporter will get email - no need to cc.
Comment 5 Daniel Black (RETIRED) gentoo-dev 2004-04-18 18:09:16 UTC
George of the lang-misc heard this is yours. You can set an email address on emu:/var/mail/alias/misc.
Comment 6 David Oftedal 2004-04-19 16:31:44 UTC
I'd like to see this added as well! I sincerely hope D will be a worthy successor to the C throne.
Comment 7 Pablo De Nápoli 2004-04-26 19:18:32 UTC
I also would like to see gentoo on portage: D seems to be a
better sucesor of C than C++, Objetive C or Java.
Comment 8 Brad Anderson 2004-04-27 09:46:50 UTC
Do we have the ability to use Bugzilla's voting mechanism or will the CC list suffice?
Comment 9 Sebastian Dröge 2004-05-05 11:14:37 UTC
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
Comment 10 Sebastian Dröge 2004-05-05 11:15:02 UTC
Created attachment 30789 [details]
gdc-0.0.1_rc6.ebuild
Comment 11 Stephan Wienczny 2004-05-06 18:58:19 UTC
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.
Comment 12 Sebastian Dröge 2004-05-07 02:20:26 UTC
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
Comment 13 Sebastian Dröge 2004-05-07 02:21:11 UTC
Created attachment 30912 [details]
gdc-0.8.2-r6.ebuild

without phobos but PDEPEND on phobos
Comment 14 Sebastian Dröge 2004-05-07 02:23:15 UTC
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
Comment 15 Sebastian Dröge 2004-05-07 02:28:26 UTC
Created attachment 30914 [details]
phobos-0.8.2-r6.ebuild

the DEPEND to gdc was wrong, fixed... it's too early in the morning ;)
Comment 16 Per Wigren 2004-05-29 10:29:32 UTC
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 ":")
Comment 17 Per Wigren 2004-07-13 06:54:28 UTC
Created attachment 35313 [details]
dev-lang/gdc/gdc-0.8.2-r7.ebuild

Updated to 20040427-patch.
Comment 18 Per Wigren 2004-07-13 06:55:11 UTC
Created attachment 35314 [details]
dev-libs/phobos/phobos-0.8.2-r7.ebuild

Updated to 20040427-patch.
Comment 19 Per Wigren 2004-10-12 15:50:17 UTC
New release:
http://home.earthlink.net/~dvdfrdmn/d/
Comment 20 Anders Runesson 2004-10-31 09:55:17 UTC
Created attachment 43022 [details]
New ebuild for gdc

Gdc is now on par with dmd compiler version 0.102
Comment 21 Anders Runesson 2004-10-31 09:57:09 UTC
Created attachment 43023 [details]
New ebuild for phobos
Comment 22 Lars Ivar Igesund 2004-12-20 23:29:28 UTC
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).
Comment 23 Anders Runesson 2004-12-30 14:10:28 UTC
Created attachment 47240 [details]
GDC 0.9 ebuild

This is an ebuild for the 0.9 release of gdc.
Comment 24 Anders Runesson 2004-12-30 14:14:10 UTC
Created attachment 47241 [details]
Ebuild for phobos in gdc-0.9

New version on GDC phobos
Comment 25 Anders Runesson 2004-12-30 14:34:32 UTC
Created attachment 47242 [details]
Fix typo in gdc-0.9 ebuild above.

Sheisse. Stupid typo... mumble.. grumble...
Comment 26 Anders Runesson 2005-01-11 06:14:06 UTC
Created attachment 48200 [details]
gdc 0.10 ebuild
Comment 27 Anders Runesson 2005-01-11 06:14:37 UTC
Created attachment 48201 [details]
phobos 0.10 ebuild
Comment 28 jose isaias cabrera 2005-01-31 08:21:02 UTC
would love to see this as a new package with gcc.
Comment 29 Stephan Wienczny 2005-01-31 08:40:26 UTC
Maybe we should change the gcc packages to include gdc. There could be a new gdc useflag?
Comment 30 jose isaias cabrera 2005-01-31 08:46:10 UTC
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.
Comment 31 trejkaz 2005-01-31 12:54:26 UTC
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.
Comment 32 jose isaias cabrera 2005-02-01 07:56:46 UTC
A separate  package is ok as long as one could emerge it. ie. emerge gdc
Comment 33 Kenny Bentley 2005-02-17 04:51:29 UTC
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 :)
Comment 34 Kenny Bentley 2005-02-20 13:12:10 UTC
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.
Comment 35 Kenny Bentley 2005-02-20 22:33:20 UTC
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
Comment 36 Anders F Björklund 2005-02-23 01:35:00 UTC
"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)
Comment 37 Anders F Björklund 2005-02-23 05:11:28 UTC
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.
Comment 38 Anders F Björklund 2005-02-23 05:19:45 UTC
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.. :-)
Comment 39 Kenny Bentley 2005-02-23 06:20:36 UTC
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 :)
Comment 40 Anders Runesson 2005-02-23 10:10:34 UTC
Created attachment 51962 [details]
hopefully fixes the gcc version problems discussed below
Comment 41 Anders Runesson 2005-02-23 10:14:17 UTC
Created attachment 51963 [details]
fixes the issues with boehm-gc and linking
Comment 42 Anders F Björklund 2005-02-25 14:35:18 UTC
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
Comment 43 Anders Runesson 2005-02-26 03:33:42 UTC
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 44 Anders Runesson 2005-02-26 03:35:21 UTC
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).
Comment 45 Nathan Evans 2005-03-21 21:27:14 UTC
Created attachment 54128 [details]
gdc-0.10-r3.ebuild

Changed DEPEND="virtual/glibc
and	RDEPEND="virtual/glibc

to 
DEPEND="virtual/libc
RDEPEND="virtual/libc
Comment 46 Anders F Björklund 2005-05-02 12:36:23 UTC
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
Comment 47 Sigbjørn Lund Olsen 2005-06-15 13:25:03 UTC
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.
Comment 48 Sigbjørn Lund Olsen 2005-06-15 13:26:29 UTC
Created attachment 61300 [details]
dev-lang/gdc/gdc-0.13.ebuild

New ebuild for gdc-0.13 (also works for gdc-0.12).
Comment 49 jose isaias cabrera 2005-06-15 15:16:23 UTC
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
Comment 50 jose isaias cabrera 2005-06-15 15:16:23 UTC
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
Comment 51 Florian RIVOAL 2005-06-19 23:34:27 UTC
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.
Comment 52 Sigbjørn Lund Olsen 2005-06-20 06:58:31 UTC
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.)
Comment 53 Jakub Moc (RETIRED) gentoo-dev 2005-08-11 13:03:58 UTC
Re-assign. 
Comment 54 Marcel Martin 2005-12-27 17:54:14 UTC
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.
Comment 55 Trevor Fancher 2006-01-03 08:40:14 UTC
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).
Comment 56 Marcel Martin 2006-01-03 09:57:01 UTC
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.
Comment 57 Trevor Fancher 2006-01-03 14:18:55 UTC
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.
Comment 58 Marcel Martin 2006-01-04 13:12:32 UTC
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/.
Comment 59 Trevor Fancher 2006-01-04 13:54:39 UTC
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<<
Comment 60 Marcel Martin 2006-01-07 05:24:51 UTC
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.
Comment 61 George Shapovalov (RETIRED) gentoo-dev 2006-01-07 11:28:32 UTC
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
Comment 62 George Shapovalov (RETIRED) gentoo-dev 2006-01-07 11:38:51 UTC
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
Comment 63 Thomas Kühne 2006-01-07 13:34:53 UTC
(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.
Comment 64 Sterling Christensen 2006-03-13 22:13:07 UTC
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?
Comment 65 Sterling Christensen 2006-03-13 22:14:43 UTC
Created attachment 82069 [details, diff]
Diff to portage/eclass/toolchain.eclass
Comment 66 Pablo De Nápoli 2006-04-24 04:53:13 UTC
I've tested the ebuild in comment #59 and seems to work 
fine. 
Comment 67 Joel Martin (RETIRED) gentoo-dev 2006-05-24 20:17:00 UTC
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.
Comment 68 George Shapovalov (RETIRED) gentoo-dev 2006-05-25 01:35:22 UTC
(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
Comment 69 Kenny Bentley 2006-06-05 02:18:39 UTC
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
Comment 70 Roel Mathys 2006-10-02 12:28:04 UTC
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
Comment 71 Roel Mathys 2006-10-02 12:30:33 UTC
I'm sorry, last step should be

6) gcc-config i686-pc-linux-gnu-4.1.1

to restore the original gcc

bye
roel
Comment 72 Jose Quinteiro 2006-11-03 13:33:18 UTC
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.
Comment 73 Martin Capitanio 2007-01-31 12:12:30 UTC
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.
Comment 74 Kenny Bentley 2007-02-06 17:22:15 UTC
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!!
Comment 75 brian-schott 2007-03-08 06:11:32 UTC
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'
Comment 76 Anant Narayanan (RETIRED) gentoo-dev 2007-03-09 18:53:15 UTC
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.
Comment 77 Anant Narayanan (RETIRED) gentoo-dev 2007-03-16 09:05:27 UTC
$ USE="d" emerge gcc

should do the trick. Closing bug.
Comment 78 Sjoerd van Leent 2007-07-13 20:04:05 UTC
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?
Comment 79 Anant Narayanan (RETIRED) gentoo-dev 2007-07-13 21:22:15 UTC
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.
Comment 80 Anant Narayanan (RETIRED) gentoo-dev 2007-07-13 21:22:41 UTC
...and really closing.
Comment 81 MageSlayer 2007-09-27 11:09:47 UTC
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.
Comment 82 MageSlayer 2007-09-27 13:15:22 UTC
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.