Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Cross platform development

By Peter Naulls. Published: 24th Sep 2004, 11:18:25 | Permalink | Printable

Building RISC OS Programs on Windows

Perhaps surprising, and certainly not obvious to many people, is that it's been possible to develop RISC OS programs under Windows for a long time. Historically, ARM's SDK environment was able to generate RISC OS binaries, although that support was removed some time ago. More recently (but has still been true for a number of years), it's been possible to build RISC OS programs using GCCSDK under Cygwin - although bugs in the version of the compiler packaged with it did make that problematic earlier this year.

As long as you follow the steps correctly, it's straightforward to setup on any Windows system. The setup for Linux (or any Unix environment) is very similar, but it is worth illustrating how to do it on Windows because that is a system that many people already have access to.

Windows Development?
Why would we want to develop on Windows in the first place? Well, the reasons are similar to why we'd want to do it on a Unix system - access to much faster hardware for compiling large programs, and perhaps more importantly, a Unix style environment in which build systems are designed to run instead of spending large amounts of time on customised RISC OS build scripts and makefiles.

Under Windows, the Linux style environment is provided by Cygwin, which gives a Unix command line shell, build environment and generally a way to develop and run Unix programs under Windows. This is important, because GCCSDK, the development system for GCC for RISC OS needs precisely this environment in which to work.

Installing Cygwin
The Cygwin installer - downloaded from its home page - is reasonably straight forward. When running it, the default options are probably fine, and choose a suitable mirror (e.g. ftp://mirror.ac.uk/) for your location. If follow the installer through, it will give you a basic setup with a Windows desktop icon that launches a bash shell alongside other basic Unix utilities.

You should then rerun the installer, and add additional packages. I recommend this 2 stage approach because when I tried to do it in one stage, I found that some of the basic packages first time around were missed. In any case, you can rerun the installer as many times as you like to manage installed packages.

On the package selection dialogue, open the 'devel' tree view. You will want to make sure you install the following packages: autoconf, automake, binutils,
bison, cvs, flex, gcc, gcc-core, gcc-g++, gperf, make. These tools are sufficient to build GCCSDK itself, but it's possible you might want to install others later to help build programs for RISC OS.

Building GCCSDK
The first step in building GCCSDK is to check it out of CVS. To do this, first start Cygwin, which will give you a bash shell in a terminal window. The CVS checkout process is outlined on the GCCSDK home page, but the exact commands you will need are:

  cvs -d:pserver:anoncvs@gccsdk.riscos.info:/usr/local/cvsroot login
(enter 'anoncvs') for the password
cvs -z3 -d:pserver:anoncvs@gccsdk.riscos.info:/usr/local/cvsroot co gccsdk


All going well, the GCCSDK source will download and will now be accessible. The instructions on building GCCSDK are detailed in its README, but again, the exact commands you will now need are:

  cd gccsdk
autoconf; autoheader
sh do-configure
make setup
make

On a fast PC this might take around 10 minutes or less. Note that the version of GCCSDK you're building is the current development version, which means there's a small chance it might not build at all, or it might exhibit issues. In practice, however, this has rarely been the case, and is in most cases recommended because of on-going improvements and bug fixes.

Using GCCSDK
If the above step went successfully (and if it didn't, the GCCSDK team would be keen to know), then not only will you have built yourself a RISC OS cross compiler, but if you look in /home/riscos/ (or C:cygwinhomeriscos), also RISC OS applications including !gcc, which you can copy directly to a RISC OS machine over a network (GCCSDK adds ,xxx filetypes to the filenames so the correct RISC OS filetypes are presented over LanMan, NFS, etc).

So what we have now is not only a way to build GCC for RISC OS itself, but a cross platform development system. Let's give it a whirl with a simple program:

#include 

int main(void) {
puts("Hello RISC OS!");
return 0;
}


Which is saved into your cygwin home directory as 'hello.c'. I can then type:

/home/riscos/cross/bin/gcc hello.c

And out should pop a file !RunImage,ff8 which is a program you can run on your RISC OS machine. And that's really the whole basis of cross compiling - the ability to construct programs on a different system.

More Interesting Behaviour
The real power of this system becomes evident if I can do something that's much harder to do on RISC OS. Compiling a simple C program is all very well, but that's easily done on RISC OS - sure, it might take a bit longer, but not too much has been gained. To demonstrate what can be done, some additional programs need to be installed, in the shape of my porting tools scripts.

If you have wget installed in Cygwin (or download the source with a browser instead), you could do something like this:

  cd
wget http://www.riscos.info/porting/scripts.tgz
cd /home/riscos/
tar xfvz /home/Peter/scripts.tgz
cd

The program I've chosen to demonstrate with is one we've just used - wget. I've chosen it because it has no special build requirements and doesn't rely upon extra libraries. I'll use the cygwin version to fetch its source:

  wget http://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar.gz
tar xfvz wget-1.9.tar.gz
cd wget-1.9

wget's build system is GNU Configure, which is probably the most widely used of Unix build systems. It provides a 'configure' script which is run directly (sometimes with options) to determine the capabilities of your system and construct suitable makefiles. If for example I wanted to recompile wget for Cygwin, this is what I would do. However, for cross compiling, the situation is rather more complex - it has to be told where the cross compiler is, where libraries are and system capabilities that it's not able to determine because it's not running on the target system. In total over many programs, these can add up to several hundred different options that might need to be set.

Fortunately, I've already done all the hard work for you, and I've provided a wrapper script that examines a program's configure script and passes it appropriate options to build for RISC OS. You can invoke it simply:

  /home/riscos/env/ro-config

After this completes, you'll then be able to build it. Sometimes, just running 'make' is sufficient, but often this doesn't work correctly for a variety of reasons. Because of this, there's also a make wrapper:

  /home/riscos/env/ro-make

Finally, once this builds, you will have a wget,ff8 binary inside the 'src' directory, which you'll find works just fine on RISC OS.

Going Further
Whilst there are plenty of programs that are as simple to build as wget, there are many more that aren't. The main stumbling block is libraries - and whilst it's certainly possible to build them yourself, it can be a bit of effort ensuring you have all the correct options and have massaged build files appropriately so that they cross compile correctly. To expedite this process, you can instead download my pre-built libraries. The tgzs provided need to be unpacked into /home/riscos/env/.

Other Systems
As I mentioned earlier, GCCSDK works perfectly will under x86 Linux, this being the system on which it is mostly used, and equally well under other Unixes such as the BSDs. Where it won't work currently is big endian systems - this includes MacOS X, and Sparc machines because some of the tools in GCCSDK aren't yet fully aware of endian swapping. The good news is that this is currently in the process of being resolved.

More on RISC OS compilation
Although the example I've mentioned here, and where much of the power of this system is relies in building ported programs, it's certainly possible to build RISC OS specific programs too. I'll not go into the details here, but libraries such as DeskLib and OSLib can be used (and themselves built) in such an environment, and the NetSurf browser is also developed in this manner.

Rounding off
I hope I've given you a taste of what's possible - it's in this sort of environment that most of my ports are developed (although I use Linux on an ARM machine). I made a recent post to the GCCSDK mailing list about future developments, which you can read here. If you have any comments, or suggestions on improvements, then feel free to subscribe to the mailing list and contribute.

Links


GCCSDK
Cygwin
RISC OS Porting tools
RISC OS Libraries
wget

Previous: ArtWorks 2.3 slated for Guildford show release
Next: German RISC OS meet

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

I can fundamentally see a flaw in our OS..

Mind you, it would be hard fetched to write core parts to an OS on the OS before it exists?

Looks like im going to have to learn C ;)

 is a RISC OS Userem2ac on 25/9/04 9:52AM
[ Reply | Permalink | Report ]

Perhaps you can explain what you think you fundamentally see, because it's far from clear.

 is a RISC OS Usermrchocky on 25/9/04 11:57AM
[ Reply | Permalink | Report ]

Does this mean that Windows based C IDEs can be used to construct programs for RISC OS?

 is a RISC OS Userjonix on 25/9/04 5:23PM
[ Reply | Permalink | Report ]

Of course. They're just files on a Windows system.

 is a RISC OS Usermrchocky on 25/9/04 6:21PM
[ Reply | Permalink | Report ]

Looks like the OSNews authors read the humble Drobe site with interest - this story has been posted to there :).

 is a RISC OS Usermd0u80c9 on 26/9/04 12:09AM
[ Reply | Permalink | Report ]

ah... that to program effectivly for our OS, (Using C) we use a different platform...THE DARK SIDE :P

Still if it gets the job done

 is a RISC OS Userem2ac on 27/9/04 9:57AM
[ Reply | Permalink | Report ]

em2ac: Except that's quite obviously not the case. You can use both GCC and Norcroft natively to produce programs. The advantage of cross-compiling with the GCCSDK is ease of use, especially when porting things from other platforms (even more so when they use the spawn of satan that is autoconf).

Take NetSurf, for example. As Peter rightly states in the article, it is generally compiled using GCCSDK on a linux machine. Why? Simplicity, above all else. I defy you to get a sensible autobuilder system working on RISC OS. However, just because the downloadable binaries are cross-compiled using GCCSDK doesn't imply that the developers themselves use this method. Certainly, some do (myself included, usually). Others compile it using GCC on RISC OS and it's equally possible to compile it using Norcroft on RISC OS (one developer at least regularly makes use of this method).

 is a RISC OS Userjmb on 27/9/04 5:02PM
[ Reply | Permalink | Report ]

jmb: Surely the other big gain is the time it takes to compile things? GCC really does show off how slow RISC OS kit is.

 is a RISC OS Usernunfetishist on 27/9/04 11:16PM
[ Reply | Permalink | Report ]

rjek: That's true, although if I'm compiling on RO I tend to use Norcroft as it's miles faster.

 is a RISC OS Userjmb on 27/9/04 11:20PM
[ Reply | Permalink | Report ]

nunfetishist: Funny, I'd have written that sentence the other way around - RISC OS kit really does show how slow GCC is.

Building Aemulor from scratch (1.2MB of source) takes less than 30 seconds.

 is a RISC OS Useradrianl on 27/9/04 11:26PM
[ Reply | Permalink | Report ]

... erm, with Norcroft on the Iyonix, that is. Fast enough that it's never a problem.

 is a RISC OS Useradrianl on 27/9/04 11:29PM
[ Reply | Permalink | Report ]

ah right, wrong terminology... my mistake.

Mind you, I still don't know whats wrong with BASIC anyway ;) not that I have made any releaseable apps lately...or ever

Still Nice article..has made me thinking about using those Acorn ANSI C and C++ books that are on my shelf

 is a RISC OS Userem2ac on 28/9/04 2:12PM
[ Reply | Permalink | Report ]

adrianl: 30 seconds?! I couldn't keep still for that long :) For a similar price to an Iyonix, you can buy a PC that compiles Linux (~25MB of source actually being compiled) in around 20 seconds.

One thing I wish the GCC guys *would* do is make sure that the time any new optimisations take to perform would effect the compiler itself at least as much as so not to increase time to take to compile :)

 is a RISC OS Usernunfetishist on 28/9/04 2:46PM
[ Reply | Permalink | Report ]

> 30 seconds?! I couldn't keep still for that long Me neither. TBH I'm often editing source, or doing something else at the same time. :)

 is a RISC OS Useradrianl on 28/9/04 4:58PM
[ Reply | Permalink | Report ]

em2ac: When considering "Cross platform development" BBC Basic is going to be of VERY limited use.

 is a RISC OS UserGulli on 28/9/04 5:07PM
[ Reply | Permalink | Report ]

Oh yeah? I thought someone had written a highly portable BBC Basic interpreter? So if you stick to pure BBC Basic without OS calls, I should think it is highly portable, as it should run out of the box on all systems with a BBC Basic interpreter.

 is a RISC OS UserJGZimmerle on 29/9/04 11:58AM
[ Reply | Permalink | Report ]

Oh, and BBC BASIC is so powerful, too! No structures, let alone classes, no decent dynamic memory management, [insert huge list of deficiencies here]... Time to move beyond the 1960s, BASIC fans!

 is a RISC OS Userguestx on 29/9/04 1:04PM
[ Reply | Permalink | Report ]

Hey, I never said I was a BASIC fan. I know of its shortcomings. But you can't deny that the comment by Gulli was a broad generalisation.

 is a RISC OS UserJGZimmerle on 29/9/04 1:09PM
[ Reply | Permalink | Report ]

I think your comment was a broad generalisation. There's no denying the availability of BBC basic interpreters for other platforms, but you can't seriously suggest that developing even medium sized Basic applications makes sense on another platform - apart from the deficiencies of Basic, you'll need RISC OS interfaces at some point which just won't exist.

Given the therefore limited use, especially in the context of this article and subsequent thread, I think Gulli's comment is reasonable.

 is a RISC OS Usermrchocky on 29/9/04 1:23PM
[ Reply | Permalink | Report ]

guestx: But you can implement structures via the ! operator, and you can write a memory manager in plain BBC Basic :) (Although it can't return memory to the OS once it has claimed it, you can 'free' it to be used elsewhere in your program.)

C has no "classes", yet GLib provides quite a nice class structure on top of it. It wouldn't be hard to do in BBC B, the point is, you wouldn't *want* to.

 is a RISC OS Usernunfetishist on 29/9/04 2:57PM
[ Reply | Permalink | Report ]

BBC Basic should be looked upon as a super scripting language. It links in very easily to all modules with the SYS call and if it doesn't have or do something then you can always write your own routine in assembler. Thus an application written in BBC Basic with SYS calls and assembler is limited not by the language but by the imagination of the programmer.

 is a RISC OS Usermripley on 29/9/04 4:18PM
[ Reply | Permalink | Report ]

I don't know about a scripting language (although it's useful for that), but it's certainly handy to have around, especially for trialling ideas, and for small applications. It doesn't seem to make a great deal of sense for cross-platform development, though.

 is a RISC OS UserSimonC on 29/9/04 5:32PM
[ Reply | Permalink | Report ]

Who's going to port Mono, then? I think it has an ARM JIT already. (Has GTK2 been reliably ported? If so, it might be a fine tool for writing cross-platform GUI apps - perhaps even write some classes to abstract further such that under RISC OS it uses the iconbar and menus in a consistant way, but on other platforms it works as normal...)

 is a RISC OS Usernunfetishist on 29/9/04 10:58PM
[ Reply | Permalink | Report ]

mripley: "BBC Basic should be looked upon as a super scripting language."

Then you haven't used any of the languages widely regarded as being suitable for scripting. For example, BBC BASIC doesn't even have any decent collection datatypes - it's "dimension an array" vs. "use the platform-specific heap allocator being careful not to stiff the machine". You'd be better off using the Bourne shell!

nunfetishist: "But you can implement structures via the ! operator"

In that respect, BBC BASIC is sort of a systems programming language, but without the conveniences provided by just about any mainstream systems programming language since the 1960s.

 is a RISC OS Userguestx on 30/9/04 5:44PM
[ Reply | Permalink | Report ]

Well, GTK apps would certainly make RISC OS Dealers who sell RAM happy.

Reasons to use BASIC: Startup time, compile time, ease of use, no fiddling about with those crazy make files, memory usage, interpretter intelligence.

 is a RISC OS Usermavhc on 30/9/04 8:49PM
[ Reply | Permalink | Report ]

mahvc>Agreed with all of the above.

In addition I always thought the EVAL function was pretty neat. Then there's the inbuilt ARM assembler (two languages for the price of one eh ?), and as assemblers go you can intermix BASIC and ARM assembler in the one program. Then BBC BASIC on the ARM was optimised to make it's subroutines fit into the ARM cache (so as to optimise performance). Sure the improvements are continuing today even - later BBC BASIC's use the assembler CLZ function (ARM v5TE only) to improve floating point normalisation.

BBC BASIC V was designed for the ARM, it's a good and efficient fit, the alternatives may have their strengths - but BBC BASIC has strengths too a point that should not be forgotten.

 is a RISC OS UserAMS on 30/9/04 9:38PM
[ Reply | Permalink | Report ]

mavhc: Err, why would having GTK apps make RAM dealers happy? Reasons *not* to use BASIC: Runtime speed, ease of debugging, ease of devloping larger projects, memory usage, interpreter itelligence.

AMS: Mixing of BASIC and assembly? Just like you can mix C and assembly in GCC?

 is a RISC OS Usernunfetishist on 30/9/04 11:03PM
[ Reply | Permalink | Report ]

mavhc> Startup speed and memory usage are two advantages of BBC BASIC (the interpreter really is a pint-sized wonder), but otherwise you've just described all the advantages of any interpreted language. And if you use a more modern interpreted language like (/me hops on hobby-horse) Python, you get a properly intelligent interpreter, and language features which really make it easy to use.

 is a RISC OS Userninja on 1/10/04 1:30PM
[ Reply | Permalink | Report ]

ninja: "the interpreter really is a pint-sized wonder"

Indeed it is, but in a land of giants, it also has pint-sized capabilities.

 is a RISC OS Userguestx on 1/10/04 2:25PM
[ Reply | Permalink | Report ]

Just how large is the Basic module?

 is a RISC OS Usernunfetishist on 1/10/04 5:49PM
[ Reply | Permalink | Report ]

rjek: you asked for this :P

OS: BASIC version: Module size (bytes):

0.30 1.00 (05 Jun 1987) 57532 1.20 1.02 (25 Sep 1987) 58420 2.00 1.04 (05 Oct 1988) 62784 3.00 1.05 (28 Jun 1991) 52208 3.11 1.05 (10 Apr 1992) 52308 3.50 1.06 (23 Aug 1993) 52620 3.60 1.14 (17 Nov 1994) 52600 3.7[01] 1.16 (01 Apr 1996) 52628 3.80 1.17 (10 Feb 1997) 55280 4.00p 1.19 (12 May 2000) 55512 4.02 1.19 (13 Jul 1999) 55392 4.24 1.22 (21 Jun 2001) 55564 4.37 1.28 (10 Jul 2003) 55632 5.02 1.34 (02 Dec 2002) 58576 5.0[3-6] 1.35 (03 Mar 2003) 58600 5.07 1.36 (21 Jun 2004) 58684

 is a RISC OS Userjmb on 01/10/04 7:32PM
[ Reply | Permalink | Report ]

<fx: slaps the lack of <pre> support in the forums>

 is a RISC OS Userjmb on 01/10/04 7:32PM
[ Reply | Permalink | Report ]

nunfetishist> But BBC BASIC does handle the assembler BASIC intermixing rather elegantly (you can basically use most BASIC statements from *within* the assembler code at compile time). Now in saying that I am not denegrating (nor would I seek to do so) GCC.

As to the BBC BASIC module sizes they're pretty modest, if you were downloading a BASIC app for an Acorn machine you could presume that the module is present on the recipient's machine - so all that is transferred is *very* compact sourcecode. Sending a C executable down the line to someone is likely to be bigger and take longer. If you send the source Ok it won't be so bad but the recipient will have to have an install of GCC or Norcroft to compile it (and trust me they *do* take up a lot more room than BBC BASIC ;).

True the size of GCC/Norcroft is irrelevant at runtime - but if you're distributing an app by internet then the size of the downloaded app does matter and BBC BASIC *does* have an advantage there.

Regards

Annraoi

 is a RISC OS UserAMS on 02/10/04 3:14PM
[ Reply | Permalink | Report ]

That argument doesn't make much sense. Firstly, you're intermixing comparisions of compile time and runtime. Secondly, you avoid the issue the SharedCLibrary, and end up with a bunch of confused points.

Yes, Basic programs will generally be smaller, but it may not be sensible or possible to develop large programs in Basic at all, so again the comparison falls flat.

 is a RISC OS Usermrchocky on 02/10/04 3:28PM
[ Reply | Permalink | Report ]

Hi Peter,

Actually there was a smiley in there when I mentioned the size of the C compilers (it was me being tongue-in-cheek really, I do know the difference between compile and runtime !). As to the SharedCLib if I mentioned that I'd slightly weaken my case slightly wouldn't I ?

Just me as usual valiantly attempting to defend the indefensible - par for the course I would have thought ;)

Regards

Annraoi

 is a RISC OS UserAMS on 02/10/04 3:43PM
[ Reply | Permalink | Report ]

Hmm, so BBC Basic isn't that much smaller than say, Lua, which does provide structures, classes, and other such modern things? And anyway, people who care about a 20% (wild approximation) different in file size between a Basic and a C program at runtime really need to get out more and just buy a new machine if it's a problem.

 is a RISC OS Usernunfetishist on 02/10/04 7:39PM
[ Reply | Permalink | Report ]

Inspired by Peter Naulls' comment: What counts as a large program ? TurtleChalk's BBC BASIC !RunImage is now up to 627 K but I guess that must still be small as it can still function fine on an A5000, and the entire package still squashes onto a single floppy disc. It's taken three years of "free time" development to get to this size but I've yet to hit any barrier due to the inherent nature of BASIC: I guess eventually I'll hit the 64000 lines of code limitation but probably not for another three years ! The EVAL function is my favourite - and string handling superb but I'm not trying to convert anyone to BASIC: Most folks become proficient in one or two languages and, unless major limitations start to prevent them doing what they want to do, are going to stick with what they know regardless of what thers say. One point: BBC BASIC is surely more acurately described as a late 70's language including, as it does, several ideas from PASCAL. It was quite an advance, in its day, on the BASICs that went before.

 is a RISC OS Usermartin on 03/10/04 09:59AM
[ Reply | Permalink | Report ]

martin: Yeah, I have some experience in large BASIC applications. !Slayer was around 700 or 800kB of BASIC, with bits of assembler. And it still ran on 1MB machines, and still trounced its competitors, that were compiled. :)

 is a RISC OS Usernunfetishist on 03/10/04 12:44AM
[ Reply | Permalink | Report ]

The main limit to how large a system can get in a simple programming language comes when you try to pass maintenance over to another developer. Languages which can express ideas more directly allow the new developer to safely alter the function of the system without understanding its entirety. A single developer who wrote the whole system may well be able to understand the intricacies of the whole system simultaneously, but that is not a sensible requirement for any other developer, who just needs to know how components of the system fit together, and how the component they're developing works in detail.

Perhaps the simplest way to explain it is: imagine writing a 500k BASIC program without using PROCs. This is the same way a C developer views using BASIC which doesn't have structs, and the same way an OO developer views using C which doesn't have classes.

 is a RISC OS Userninja on 04/10/04 5:19PM
[ Reply | Permalink | Report ]

It's OK to criticize BBC BASIC but I'm wondered about the fact that it isn't developed further substantially. In the past I often heard that it is not very well documented so that it isn't easy to make enhancements to BBC BASIC. However, why not guys like Sophie Wilson (aka Roger Wilson) will TODAY document what they have done with BBC BASIC? They could enhance BBC BASIC (speed optimisations, new structures, new keywords and so on) and cultivate this wonderful piece oft software. BTW, of course I would pay (not only peanuts) for this. And since I'm using BBC BASIC I have got a lot of ideas what could/should be done, and over the years I wrote a big wish list. So my request to all who can help; develope BBC BASIC further, please.

 is a RISC OS UserGollum on 04/10/04 8:59PM
[ Reply | Permalink | Report ]

Or alternatively, provide a different BASIC all together? There's always the possibility or porting something like BAX, which is a QuickBASIC/PowerBASIC alike that converts to C, and includes things such as structs and other 'modern' programming concepts.

 is a RISC OS Usernunfetishist on 04/10/04 10:04PM
[ Reply | Permalink | Report ]

Or alternatively, provide a different language altogether? One that's already been ported, even. There are other good interpreted languages that are no harder for the beginner, and are more standard, allowing developers from other platforms to bring their software to RISC OS easily.

 is a RISC OS Userninja on 05/10/04 1:30PM
[ Reply | Permalink | Report ]

ninja: Most RISC OS advocates prefer languages with small footprints, quick runtime speed as well as ease of use. Python and Perl simply don't fit any of the three. The only one that's been ported that I know of is Lua, and that's not really designed for large projects, either. (Although it's certainly a lot easier to manage large projects with it than BBC Basic.)

 is a RISC OS Usernunfetishist on 05/10/04 2:20PM
[ Reply | Permalink | Report ]

I agree that both Perl and Python have massive interpreters, espectially as compared to the diminutive BASIC interpreter (as I mentioned earlier, I think). That's a disadvantage. But I don't know what you mean by quick runtime speed - while Perl and Python take a lot longer to start up (in the order of a second, as compared to in the order of instantaneous with BASIC), once they're going they seem faster to me. And as for ease of use, I think that Python, and Perl to a lesser extent have very well balanced learning curves. The 'hello world' program is as easy in any language, and beyond that list handling is much more intuitive in either language than in BASIC. Perhaps forcing people to indent their programs when writing Python is a little strict though.

Sadly I'm not familiar with Lua, so I admit I probably don't have the full picture when it comes to interpreted functional languages.

 is a RISC OS Userninja on 05/10/04 4:21PM
[ Reply | Permalink | Report ]

Think I'm missing a little thing. After several times trying to install (about 20x) gccsdk it still gives me an error:

after downloading and typing in exact the commands I end up with the error:

configure: error: invalid package name: riscos-pkg

(after typing in cygwin sh do-configure)

google or the gccsdk mailing list has nothing about this problem so it must be (a little) fault here.

so please give me the tip to correct this.....

 is a RISC OS UserEasyKees on 06/10/04 11:11PM
[ Reply | Permalink | Report ]

I wonder why you needed to try 20 times - the details aren't going to change. Please report full details to the GCCSDK mailing list, including any other previous messages.

 is a RISC OS Usermrchocky on 07/10/04 04:35AM
[ Reply | Permalink | Report ]

20 times installing again and again... reason why :

a) I have a lot of time b) tried different servers and or PC's c) I could not find any more users with the same problem so it is clear that the fault is here and not in the article on installing gccsdk d) I'm a newbie on C, C++ and so on so before asking 'stupid ' questions on the mailing list I try different things first.

 is a RISC OS UserEasyKees on 07/10/04 8:05PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Drobe price comparison chart
    Checking out the competition
     21 comments, latest by govind on 14/11/03 2:15PM. Published: 9 Nov 2003

  • Random article

  • Updated menu and drawfile support in Dr Wimp
    Version 4.70 of programmers' library released
     Discuss this. Published: 1 Mar 2007

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Oh, and books are freaking books, not dead trees, for gawd's sake"
    Page generated in 0.3203 seconds.