[gccsdk] Release checklist
peter at chocky.org
Thu Dec 24 08:10:48 PST 2009
alan buckley wrote:
>> On Wed, 23 Dec 2009 15:22:07 Peter Naulls wrote:
>> I've updated all the bits for package generation, but ran into a variety
>> of fun RiscPkg issues, which just tell me packaging on RISC OS still
>> needs lots more work.
> I've been creating and using test GCCSDK packages for a while and have
> had no real problems. What are the problems you are having? My
> Iyonix is currently running a GCC4 from packages I made last week.
No, these are more general problems, and really a different topic.
Most notably, there are a number of differences between riscpkg.org
packages and and riscos.info ones. And also I'm not sure if
(since it's not documented) RiscPkg provides the full range
of Debian headers like "Provides" and others, which might be
convenient in resolving this. It also look me a long time
to resolve a mystery "malformed URL" error. It turns out that
RiscPkg had conflated the unixfont and unixhome pages (due
to an error on my part), but there's lots of opportunities for
> Actually having said that, the packages I made rely on running of
> !GCC first to set the paths etc before using the compiler. Did you
> go further and add command aliases? Was this where the problems lay?
No, we haven't added these. Perhaps we should. I don't think it
matters so much - this is how GCC has always worked.
>> In the meantime, I think it'll be ok for this
>> release, although at present the test packages I made for the C and C++
>> compiler are apparently mutually exclusive to !RiscPkg.
> I'm not sure what you mean by this. But there is a clash between the
> GCC version shipped on the current RiscPkg site and the GCCSDK
> packages because they both use the !GCC directory. I thought the
> GCCSDK packages had a Conflicts line in it to warn of this.
Just what I said, and apart from the deliberate Conflicts with the
older riscpkg.org package, selecting the C compiler deselects the C++
compiler and vice-versa. This is despite the dependency of the latter
on the former.
> I actually think it is quite a good idea to ship the dynamic ELF
> version of the compilers. It gets them tested by what will
> probably be slightly more techinical users.
Whilst that might be true, it's something of a limited set of
binaries, which in any case seem fine (I've used them too before),
and creates a further hurdle for first time users. The elf2aif
and -static flag creation will be enough confusion as it is, and
there are still apparently quite a number of people holding onto
Norcroft for arbitrary reasons (see latest csa.p).
More information about the gcc