Surprisingly gcc-3.4.3.20050110-r2 has dissapeared from portage and it is a dependency of the two versions of gpc currently in portage.
Ok, I am looking into it. I will most likely issue an update (there is a semiofficial "stable" 20051104 version) and will kill the gcc dependency - it is not strictly necessary, emake just have to be changed back to emake bootstrap.. Another thing to look into: can gpc be hooked up to gnatbuild eclass (see #111340), or is there sufficient common functionality that could be made into another eclass inherited by both? Although I doubt I'll get to this any time soon if the update now works, so if anybody feels interested you are wellcome to try :). If you do, please wait a few days, until I perform some cleanups and commit gnatbuid.eclass and everything related to portage (p-masked at this point). George
In portage. The build/installation is revamped somewhat, to make it more consistent with how toolchain does gcc. I do *not* use gnatbuild.eclass, as I was thinking I might - there is not that much stuff in common afterall. However if there is an interest in setting up multilib or crosscompilation properly some more functions may be adapted.. The ebuild performs emake bootstrap now, so matching gcc backend is no longer necessary, as C compiler is built and its backend is installed under gpc specific LIBEXEC location. The ebuild creates an env.d entry, which only has a PATH element at present (pointing at backend). This should not interfer with active gcc (it is called via wrapper), but if you happen to have problems, please report. Then gpc invocation will have to become quite a bit fancier.. It would be nice to have that entry provide a path to the gpc units, but I did not find a way to do this via env var, only commandline switch to gpc is mentioned in ifno page. If you know how this can be done, please comment, I'll add this to the env.d file.. (Not closing yet, I am going to request testing on sparc). George
Hi sparc team. I noticed that gpc-20040516 has ~sparc in its KEYWORDS. Now, all the older versions have a hard dependency on gcc-3.4.3, which is now gone from the tree. I just issued an update, which no longer depends on gcc and I tested it on x86 and amd64 (both ~ atm). Therefore I would like to request testing of this package on sparc, so that I could remove broken versions from the tree. (They are all in "~" now, so a simple report of "it works" is fine at present. You can even add ~sparc to KEYWORDS yourself, just tell me then that I can remove older versions. I'll raise a stabilization request at a later point, as proper..). George
Works fine except for a minor detail - you forgot ROOTPATH in env.d/56gpc thus only users could use it. I fixed the ebuild to add the proper ROOTPATH too and keyworded ~sparc.
Hm, this should have been closed long ago..
