Message from discussion 32-bit SharedCLibrary on the A9

Path: g2news1.google.com!news4.google.com!news.glorb.com!news2.volia.net!news-out.ntli.net!newsrout1-gui.ntli.net!ntli.net!newspeer1-win.ntli.net!newsfe5-win.ntli.net.POSTED!53ab2750!not-for-mail
From: James Peacock <n...@jip22.freeuk.com>
Newsgroups: comp.sys.acorn.programmer
Subject: Re: 32-bit SharedCLibrary on the A9
Message-ID: <0b9c2db24d.james@iyonix.local>
References: <19f529b24d.philip@philipnet.com>
Lines: 35
User-Agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.10) NewsHound/1.43-32pre3
Date: Thu, 29 Sep 2005 21:26:18 GMT
NNTP-Posting-Host: 82.13.58.61
X-Trace: newsfe5-win.ntli.net 1128029178 82.13.58.61 (Thu, 29 Sep 2005 22:26:18 BST)
NNTP-Posting-Date: Thu, 29 Sep 2005 22:26:18 BST
Organization: NTL

Philip Ludlam wrote:

> I've got a bug report from a user using some of my software on an A9.
> 
> He comments that the software *RMEnsures SharedCLibrary 5.17 , but he's
> running version 5.02 (!)
> 
> In the dim and distant past, the RMEnsure of version 5.17 or later was
> used to ensure that a bug-free enough version of the SharedCLibrary
> produced by Pace was used on all previously available machines.

You could (and I'm not saying this is a good idea) probably come up with
various RMEnsures on the UtilityModule to work out if you have a 32bit
ROL RISC OS and lower the requirement in that case. This sort of stuff
should not be necessary.
 
> Now, with the advent of the A9, it seems that RISC OS Developments have
> produced their own 32-bit version of the SharedCLibrary.
> If one was being particularly bitter one might assume that there's still
> a big dispute between ROD and Castle ;-) .

I'm in a similar situation, only my software depends on C99 features and
I've been informed by users that the Castle SCL is incompatible with the
A9 version of RISC OS. The workaround appears to be to use StubsG though
in my case, StubsG is no help as old 26bit SCLs don't support C99 :-(

> Presumably this version of the SharedCLibrary is going to find it's way
> onto other ROD products (maybe even Select 4!) so I'm going to have to
> bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of
> the other SharedCLibrary isn't lurking around anywhere.

We really shouldn't be having these problems with such an important
module...

James