Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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..