gcc4_7_4-rel6 problem

I have something that compiles with gcc4_7_4-rel5-1 but not with gcc4_7_4-rel6 in otherwise identical circumstances. Instead it says

Unable to locate GOT of client:

<builtin>:recipe for target ‘lapi.o’ failed.

Unable to locate GOT of client

Curious, so I Googled and… I suspect it may be the same thing you listed on the GCCSDK mail list on the move from release gcc4_7_4-rel3-1 to gcc4_7_4-rel5

On 05/08/2021 12:53, wra1th+gavin wrote:
> What am I doing wrong? I downloaded gcc4_7_4-rel5 and when I tried to
> use it I got the error message Unable to locate GOT of client. The same
> source files compiled with gcc4_74-rel3-1.

That thread is here:
http://www.riscos.info/pipermail/gcc/2021-August/thread.html

The last question from Lee when the thread ends with no reply:

>> readelf -e
>> /SCSI::HardDisc4.$/Programming/GCC/noar/!GCC/bin/../libexec/gcc/arm-unknown-riscos/4.7.4/cc1 
>>
>>
>> The size of that binary here is 12,889,608 bytes.
> 
> So is mine. Attached is the output from the readelf commands.

Well, that's definitely not right. I wonder if your files are getting
corrupted somewhere between the initial download and unzipping. Can
you download them with Netsurf directly in RISC OS?

Presumably you got eventually rel5 to work somehow?

Presumably you got eventually rel5 to work somehow?

Yes, I did, thanks. It was back in August that I was having trouble and did not know which apps were corrupted: SparkFS, NetSurf, … . Things are a little better now, and I have even been able to correct same faults on my Fat32 disk using fsck, thanks to advice from Druck. I had better try downloading gcc4_7_4-rel6 again and do some checking.

Aah, I am back with the old problem that I cannot download from https://ci.netsurf-browser.org/builds/riscos/
because NetSurf keeps reporting that there is no available space on the disk, which is nonsense. This is with NetSurf 3.10 and with 3.11 (#5318). Is this a NetSurf problem or a SparkFS problem?

Panic over. I redownloaded gcc_4_7_4-rel6-1 with NetSurf 3.11 (#5319) and now everything compiles.

It sounds like something is poorly/not reliable with your FAT FS. Have you tried using a Filecore formatted drive instead? I wouldn’t recommend running RISC OS apps from FAT or directly from SparkFS, especially anything that might rely on filetypes/permissions/timestamps/etc

Have you tried using a Filecore formatted drive instead?

Does SCSIFS come under that description?

Yes – anything ADFS, SCSIFS, IDEFS, RAMFS run on top of Filecore. But not Fileswitch FS like DOSFS, FAT32FS, SparkFS, HostFS.

In theory it shouldn’t matter but Fileswitch FSes have their own implementations of every filing system op and, given the lack of a FS test suite, it is possible they do something subtly wrong. Most software might not notice, but some could behave differently.

Yes – anything ADFS, SCSIFS, IDEFS, RAMFS run on top of Filecore. But not Fileswitch FS like DOSFS, FAT32FS, SparkFS, HostFS.

Thanks for that. I have almost everything that I had on the FAT32FS disk now on a SCSIFS disk which I will now use instead. I noticed some while ago that lots of applications had files with the wrong filetype. Is occasional loss of filetype likely to be down to the use of Fileswitch FS?

Is occasional loss of filetype likely to be down to the use of Fileswitch FS?

It’s more likely down to the hacks involved in storing filetype information on a FAT format that doesn’t provide anywhere official to store it. I recall there were issues with floppies if you took a RISC OS disc to a PC, wrote a file and brought it back – filetype info would get corrupted (the bottom byte would get cleared, ie &FFF became &F00) because Windows rewrote the directory entries without knowing about RISC OS filetype metadata. It is possible something similar happens if you move a USB stick to a PC or dual-boot Linux on a Pi.