gccsdk error

hi guys
i am trying to instal gccsdk and i got this error

internal error abort on data transfer & 0000000

i have ROM v4.02, soft load to 4.39
i have installed everything in v4.7.4 package and i have “merged” the shared lib to !system

when i open the RiscOS shell and i type “gcc -v” i got that error

what’s wrong ?

following this guide

i am trying to instal gccsdk and i got this error

You mentioned merging !System modules, but have you installed !SharedLibs in a place where it will be seen. One such place is the !Boot.Resources directory. Otherwise double clicking on !SharedLibs first will let it be found. I would have thought the error would be more informative though.
Have you made a wimpslot big enough for running !GCC?

i also tried gcc v3.4.6 and 4.1.1

they say “not enough memory, application requires 4-6Mbyte”

> You mentioned merging !System modules, but have you installed !SharedLibs in a place where it will be seen.

done, they are inside the gcc-4.7.4 folder

> Otherwise double clicking on !SharedLibs first will let it be found.

already done, clicked on

> I would have thought the error would be more informative though.

no more info from the shell, unfortunately

> Have you made a wimpslot big enough for running !GCC?

what is wimpslot ?

edit
ops, i was not caring about wimpslot

is it possible to make it permeant ? i mean 8Mbyte always allocated to gcc ?

is it possible to make it permeant ? i mean 8Mbyte always allocated to gcc ?

There is a few ways to do this, perhaps you could start with adding a line like
TaskWindow "gcc -v" -Wimpslot 10000K
To the bottom of !GCC’s !Run file.
Then clicking on !GCC will start you the taskwindow with the allocation. I dont know what size exactly you will require in use.
Other packages like this !FLAC example use an alias
in their !Boot (again it’s parent directory must be seen by the filer first)
Set Alias$flac WimpSlot -min 3606k|MRun <FLAC$Dir>.flac %%*0
The size requirement may vary in !GCC with different loads. I just use a really big one to be safe.
If you have hidden !SharedLibs from the filer you will have to include a line at the end of !GCC’s !Boot like
Filer_Boot <GCC$Dir>.!SharedLibs
Including it in !Run instead would delay filer booting until you have clicked on !GCC which may be OK too.

Can somebody supply a link to the RISC OS welcome guide or RISC OS User guide perhaps? Otherwise you’ll have to find individual’s sites with RISC OS tutorials. The Archive DVD is packed with articles and is a bargain. There are worthwhile online publications too.

I think a recent OS will automatically extend the wimpslot if you *something and the current task doesn’t have enough memory. But that’s not much help here.

It should also be said that the simplest way to change the memory allocated to subsequent task(s) you run is to drag the Next bar in the Task Manager. If you want to make it semi-permanent you could do is *WimpSlot -next 8192K and put that in !Boot.Choices.Boot.Tasks or similar. That will set the ‘default’ Next slot – but you can still drag it with the Task Manager to change it.

Be aware if you run lots of Task Windows that this will cause you to run out of memory eventually though, as each will get allocated 8MB.

Are you using a Task Window or a ShellCLI prompt (by pressing F12)? I can’t remember what ShellCLI does about memory.

i am using ShellCLI

Set Alias$flac WimpSlot -min 3606k|MRun <FLAC$Dir>.flac %%*0

I have just noticed trying this with gcc and for some reason, it will only work if you dont use the extra % (which is normal use within an alias).
This is puzzling, and it would pay to look out for other mishaps using that method.
If you were to believe F12 CLI for gcc 4.1.2 it needs a min of 6000K.
Normally you would run from a Taskwindow to run make which can in turn can call other utilities, so something much larger is likely to be needed. Using the next slot does not cover you for any spawned process’s from the unixlib side, so you need to allocate extra beforehand. Or can it? I haven’t really used anything other than a large enough slot for a while.
It raises the question that if (unixlib) make was to call gcc that has been aliased a wimpslot in the above way, does the make task still need a large initial allocation?

Set Alias$flac WimpSlot -min 3606k|MRun <FLAC$Dir>.flac %%*0

Using ‘wget’ as an example, this is in its !Boot obey file :-

Set Alias$wget WimpSlot -min 2154k|MRun <Wget$Dir>.wget %%*0

Inspect what the alias has actually been set to in a TaskWindow :-

*show *wget*
Alias$wget : WimpSlot -min 2154k|MRun SDFS::RISCOSpi.$.Boot.Resources.ToBeBoots.!Wget.wget %*0

There is a very exact answer to this apparent conundrum which is incompatible with the forgetful brain.

Approximately then the Obey file is passed to GSTrans and the trailing argument needs to be ‘escaped’ whereas a directly entered command is just that, no GSTrans that is. See “Command scripts” in the PRMs Vol 4.

If you don’t use the extra % the %*0 will be filled in with any arguments to the obey file where you created your alias. Assuming there aren’t any, your alias becomes

'Set Alias$flac WimpSlot -min 3606k|MRun <FLAC$Dir>.flac '

Try show ‘alias$flac’ Note the space at the end of the alias – it won’t work without it because the alias expansion adds all arguments after the last argument used in the alias to the end of the alias.

For example if at a command line you put – the quote marks are so you can see the spaces and the line after the alias call is the output from the alias:

'set alias$test echo %0'
test a b c d e f
ab c d e f
'set alias$test echo %4 %0'
test a b c d e f
e af

%%*0 should work. If you replace Run in your alias with echo you will see how the alias is expanded.

i am shocked, there is no gcc working on my system!

i have installed

• v2.95 → missing libraries, missing headers, but it runs without error and it does not need any WinpSlot set
• v3.4.6 → it needs WimpSlot, i have set -Min 6000K -Max 8000k, trying to compile hello.c says “internal error” and it crashes
• v4.1.1 → it needs WimpSlot, i have set -Min 8000K -Max 10000k, trying to compile hello.c says “internal error” and it crashes
• v.4.7 → crashing immediately once launched

Try this:
Go into Task Manager and drag the Next bar up to 16MB (just to give plenty of space)
Press Ctrl-F12 to open a TaskWindow
Try GCC in there

2.95 is hopelessly out of date, but you should be OK with 3.x or 4.×.

To be clear, you have a folder called ‘c’ and a file called ‘hello’ (no extension) inside it?
Or a file called hello/c ?

How much RAM do you have?

hi
i have 66Mbyte of ram, 2 sim72-modules of 32Mbyte installed, 2×32=64Mbyte + 2Mbyte on the modo, plus 1Mbyte of Vram

it seems the problem is the UnixLibrary, i have installed a new one (the last one available) clearing everything in the !Boot

i have installed gcc 3.4.6, everything in the 4.* is crashing with “internal error when transferring ….”

i have an example called hAllo, it’s in the hAllo folder

/examples/hAllo
/examples/hAllo/C/hAllo → C source
/examples/hAllo/H/hAllo → header

C/hAllo is something like

#include
int main()
{
print(“hAllo from RiscOS\n”);
}

i have changed the “current working directory” to /examples/hAllo

i invoked
WimpSlot -Min 4000k -Max 8000k
gcc hAllo.c

i got a binary fine that is working as expected

gcc v4.* is not working at all
gcc v2.95 is saying cpp0 internal error

also, it seems i can’t invoke “FileCore”, that is a UNIX support, something like “ls, cd, mkdir”
RiscPkg is installing it, i have removed, because if i invoke it, gcc-v3.4.6 says there is a “SWI error” and it stops

i think i need a bit of voodoo X____X

to summarize, i had success
0) installing the last one UnixLibrary
1) removing FileCore
2) setting WimpSlot
3) invoking gcc v3.4.6

everything else fails

something strange happens if invoke “fileCore” (from PackMan). This application contains “ls, cd, mkdir, ecc”, something like Unix support: if i invoke it then i am not able to compile anything with gcc

A) WITHOUT! invoking fileCore
gcc v3.4.6 compiles fine

B) invoking fileCore (e.g. indirectly called when you type “ls” )
gcc says “SWI value out of the range for module sharedClibrary"

i found documentation for sharedclibrary , but i am not able to understand the error i get

%%*0 should work

Colin you may have misunderstood me, the flac example is working fine, it is when
Set Alias$gcc WimpSlot -min 8000k|MRun <GCC$Dir>.bin.gcc %%*0
assuming <GCC$Dir> has been created by !GCC’s !Boot of course.
The result of
gcc -v
is
gcc: %*0-v: No such file or directory
Drop one % in the alias and it works fine, that is why I said, it is differing from the norm.
One difference in the structure to the others is the extra path component (.bin), however removing this and moving the gcc binary to match doesn’t change things.
I should add I’m on Iyonix v5.20 in case others aren’t finding this oddity.

Edit: Just read Davids post a second time and it clicked, that I was setting the alias at the command line rather than in an Obey file, That is the difference, solving my puzzle.
Seems a manually created alias is not always the same thing. GSTrans and all that.

In that case you still have me confused. Is the alias created in an obey file or at the command line? The error you get implies that you are creating it at the command line as you only need a single % when creating an alias from the command line.

The error you get implies that you are creating it at the command line as you only need a single % when creating an alias from the command line.

Yes that is it exactly, thanks.

good idea, i have put the “Alias” inside the boot script: it’s working marvelous with gcc v3.4.6 =D

I have downloaded the GCC4_4/7/4-Rel-1/zip package from riscos.info and it /does/ error with
Internal error: abort on data transfer at &000085A4
I will report it on the gccsdk mailing list.
I would have thought 4.1.2 to be OK but haven’t tried it lately.

Edit: I noticed there is a specific !SharedLibs for 4.7.4 but that doesn’t seem to help, I’ll try rebooting.

something strange happens if invoke “fileCore” (from PackMan). This application contains “ls, cd, mkdir, ecc”, something like Unix support: if i invoke it then i am not able to compile anything with gcc

I think you are talking about !CoreUtils package here. I can remember a problem with !CoreUtils setting variables/alias that conflict with existing RISC OS commands. Once that is fixed I think it behaves OK.

I have downloaded the GCC4_4/7/4-Rel-1/zip package from riscos.info and it /does/ error with Internal error: abort on data transfer at &000085A4

gcc 4.7.4 release 1 is OK here on both the Raspberry Pi and OS4.39 VRPC. As expected it needs a 6MB WimpSlot to do gcc -v and an even bigger WimpSlot, e.g. 15MB, to compile anything. In either case the resulting error clearly indicates insufficient memory.

!SharedLibs is version dependent, but if gcc cannot find the requisite libraries it does error to that effect. The library file names are different so it is sufficient to drop the new !SharedLibs over the old. I have one copy of !SharedLibs in !Boot.Resources and can run either gcc 4.7.4r1 or 4.1.2r2. (just in case it is relevant nothing earlier than 4.1.2r2 has been on either machine.)

I have just downloaded a fresh gccsdk-gcc-bin-4.7.4-Rel1.zip from http://www.riscos.info/downloads/gccsdk/latest/ and that is all good too.

Some diagnostics :-

*show gcc*
GCC$Description : C/C++ compiler and development suite
GCC$Dir : SCSI::SSD120.$._Temp.!GCC
gcc$heap : 
GCC$Help : SCSI::SSD120.$._Temp.!GCC.docs.index/html
GCC$Publisher : GCCSDK Developers
GCC$Title : GCC
GCC$Version : 4.7.4 Release 1
GCC$Web : <a href="http://gccsdk.riscos.info/">http://gccsdk.riscos.info/</a>
GCCbin$Path : SCSI::SSD120.$._Temp.!GCC.bin.
GCCSOLib$Path : SharedLibs:lib.,
*show SharedLibs*
SharedLibs$Dir : SDFS::RISCOSpi.$.!BOOT.Resources.!SharedLibs
SharedLibs$Path : SDFS::RISCOSpi.$.!BOOT.Resources.!SharedLibs.
*

I had the briefest of plays with GCC 4.7.4 last night on my Iyonix with RO 5.22. I deleted all my installations of earlier versions, then installed the GCC binaries and the shared libraries app. My !System and UnixHome were already up to date so I didn’t need to install them. I just compiled the HelloWorld example in RAM disc with a command line something like:

gcc RAMdisc0.$.c.helloworld -mlibscl -O3 -o RAMdisc0.$.hello

(I apologies for any errors – that’s from memory and I’m not in a position to try it here and now). Anyway, the result was an app that did what you’d expect.

As an aside, the first time I tried it, I didn’t put in the -mlibscl (or -O3) arguments, and, when I clicked the mouse after the app had run, it took the Iyonix down.

I can confirm that 10240 kiB was not a big enough Wimpslot to compile it, but 15360 kiB was.

As an aside, the first time I tried it, I didn’t put in the -mlibscl (or -O3) arguments, and, when I clicked the mouse after the app had run, it took the Iyonix down.

Hmm!! The command below produced a non-crashing ELF non the Raspberry Pi.

gcc RAM::RamDisc0.$.c.CHello  -o RAM::RamDisc0.$.Hello

Some ELF diagnostics :-

*show *E1F*
Alias$@RunType_E1F : SOMRun %*0
File$Type_E1F : ELF
*
*help SOManager
==> Help on keyword SOManager
Module is: Shared Object Manager   2.10 (01 Dec 2014) (c) GCCSDK Developers

Commands provided:
SOMStatus       SOMAddress      SOMExpire       SOMAllowQuit    SOMRun  SOMHistory
*

I sidelined the old !SharedLibs and used the new downloads and things are working now. I better scoot back over to the mailing list and undo the false report.
Edit: for the op, I downloaded and installed/merged SharedLibs_4/0-Rel1-1/zip,SharedLibs-C2_4/7/2-Rel1-1/zip and SharedLibs-C++2_6/0/17-Rel1-1/zip

> I think you are talking about !CoreUtils package here.
> I can remember a problem with !CoreUtils setting variables/alias that conflict with existing RISC OS commands.
> Once that is fixed I think it behaves OK.

can you tell me more ?

if i invoke !CoreUtils (that is the right name, i had “renamed”),
then i get error SWI value out of the range for module sharedClibrary as soon as i try to run gcc