getting gcc for hppa into the archive
Matt Taggart writes:
> At this point I think the toolchain has stablized enough that I'd like to get
> proper debs into the archive. All of our diffs have been accepted by upstream
> but on the 3.1 branch. IMHO the diffs are too large to just add to the current
> 3.0 package. So I see two possiblities,
for my understanding: these are backports of the hppa 3.1 checkins to
3.0, or complete diffs from 3.0 to 3.1 including the hppa patches?
what size are the packages? currently we do the same for mips and s390
in the 2.95 branch.
> 1.) Produce hppa specific gcc debs using either the port's CVS or the upstream
> 3.1 branch. I could do the packages and they would have no affect on the
> compilers for other archs. This would be redundant packaging/tracking work
> that would be needed until the regular debian package contained all the hppa
assuming these packages will be uploaded to unstable, we'll have the
binary independent packages for the other archs as well.
> 2.) Do a general gcc-3.1 based on the upstream 3.1 branch. Teach gcc-defaults
> to use 3.1 for hppa.
> This gcc-3.1 package could either be "Architecture: any"
> or just for hppa and other ports that needed it. IMHO This is a more
> appropriate solution and might be useful for other archs. Exposure would be
> limited to the archs using 3.1. This might be more work for the debian-gcc
that would be in the "tradition" of the experimental packages. but if
this package is regularly updated to the HEAD, it becomes difficult
to get a stable compiler, especially if more than one architecture is
using HEAD for it's main compiler.
> In addition to needing hppa gcc debs I also need to do hppa64 cross compiler
> debs(mostly for building 64bit kernels). I am hoping to use the GCC_TARGET
> environment variable thing in the 3.0 package but haven't started working on
> it yet. This may have some impact on what to do for the normal gcc debs.
what I've learned from 2.95 and 3.0 is to cleanup the build files
before branching the debian subdir. Now we have two different build
procedures. Chris, we should propose a policy for
"cross"-packages .... Maybe we get support from the Emdebian project
> How would you like to see these packages done? Any other ideas?
I cannot comment which version is more stable to use for
hppa. Assuming that 3.0 stabilizes in the near future, the size of the
patch set isn't a reason not to rely on 3.0. It seems to work for mips
and s390. Does it to make to track both versions as it's done for 2.95
and 2.0 for the other archs (for hppa 3.0 and 3.1)?