OSLib and ELF

[David J. Ruck]

On 10 Apr 2007 John Tytgat <John.Tytgat at aaug.net> wrote:
> I haven't said "laziness", I've said "relevant".  I don't think making
> *new* OSLib releases containing APCS-R libraries are relevant anymore,
> especially when it is going to be labeled '7.00' i.e. major new release.

I don't see a problem with freezing the APCS-R variant at 6.9 and not 
providing additional releases. There are a few systems which can't be 
rebuilt for 32bit without extensive re-QA'ing, which might need a new 
version to fix any bugs. But given how lightweight and stable OSLib 
is, the chance of that is vanishingly small, and its well within the 
capabilities of anyone maintaining it to rebuild an appropriate 
version from source - as long as its possible on RISC OS.

> However seen the very long build times on RISC OS I'm not candidate to check
> this out myself.  I'm very happy to help and work together with someone else
> taking care of those changes for RISC OS native build but on the other hand
> is it worth to do these efforts today ? So far we've only Tom who wants to
> build DefMod2 natively using his own build setup so he's not going to be
> affected by such a change.  And we have Druck who finds it "very important".
> But at what expense ?

It is essential that a RISC OS box can build all the sources to 
critical components, no matter how long the build time is. Any general 
purpose computer platform that is incapable of tying its own shoelaces 
is not worth using.

> In order to avoid all confusion for others: APCS-R and APCS-32 are ABIs and
> are independant from the object fileformat used (i.e. AOF/ALF vs ELF). So
> we can rephraze this question into: OSLib (AOF/ALF APCS-R), OSLib32
> (AOF/ALF APCS-32) and OSLib-ELF (ELF APCS-32).  And yes the ELF support
> means a separate version.  Not only the binary (library) is different, but
> also the ASM headers.
> 
>> I assume there will be no changes to the C and ASM headers;
> 
> No changes foreseen for C headers, but the ASM headers will be different
> for gas assembler syntax.

It may well be possible to avoid that, unless any of the headers 
happens to trip over Objasm problems with conditional compilation 
blocks, as I found when building UnixLib with Norcroft rather than 
GCC. The latest Castle Ojbasm is necessary to work around this.

>> we would need to maintain the deep, wide, and UNIX directory structures.
> 
> I would question the relevancy of 'deep' as well today.  My guess is that
> most, if not all, OSLib users are using a FS which doesn't have the old
> FileCore number of objects limitation.  But that's probably raising the same
> arguments for APCS-R and native build support... :-/

Agreed on freezing the legacy APCS-R and deep, and continue with 
APCS-32 in ALF and ELF for future releases, or its just making 
unncessary work. But native building is a completely different issue 
and is more about whether the platform is fit purpose and worth 
investing further time in.

Cheers
---Dave

-- 
______________________________________________________________________

David J. Ruck   Phone: +44- (0)7974 108301   Email: druck at druck.org.uk
______________________________________________________________________