Experimental new NetSurf builds

We have added an experimental new RISC OS toolchain to the NetSurf auto builder.

From build #5415 onward, RISC OS downloads are available in two different variants.

arm-unknown-riscos

Downloads with this in the filename are built with the original GCC 4.7 based compiler. It produces binaries compatible with all RISC OS systems.

arm-riscos-gnueabi

Downloads with this in the filename are built with the new toolchain, containing a GCC 10 based compiler. It produces builds that require both RISC OS 5 and a StrongARM or newer hardware. So it will NOT work on an RiscPC without a StrongARM card, an A7000 or a RiscStation, etc.

Being based on a more modern compiler, it should be capable of making more advanced optimisations and therefore yield quicker binaries than the old toolchain.

The builds are available from the NetSurf CI server.

Please try out the new builds and let us know how you get on.

Best regards,
The NetSurf Developers

Assuming you’re looking here – if I don’t see a response within the next 24 hours or so, I’ll respond to the list…

Question: how do we know for sure which version we’re actually running? AFAICS the Info window doesn’t distinguish between the builds. The one that I think is running, the second line of the Log file ends in “machine <armv71>”, so is that the EABI version?

Suggestion: you have a LATEST file that contains the leafname of the latest arm-unknown-riscos build. Maybe you could add a file LATESTEABI or similar, to give the leafname of the latest gnueabi version? That would make it easy to switch the FetchNS app over to pick the GNU EABI build instead.

The new compiler variant works well here on a few quick tests with an ARMX6 & RO5.29 – speed looking good so far.

Maybe, I am doing something wrong – but the download of any version of Netsurf no longer works for me.

Using Netsurf 3.11 on Pi 4 running RO 5.28
or
Firefox 52 on Windows XP

EDIT: Sorted. Mea Culpa.

Very good, thank you.

As already mentioned the two builds are indistinguishable in use. To tell which is which on the disc then inspect the respective !Run files, one uses the ARMEABISupport module and the other does not.

The new build does look to be a sniff faster, 5%-ish??, as very briefly tested on the Titanium.

Question: how do we know for sure which version we’re actually running? AFAICS the Info window doesn’t distinguish between the builds. The one that I think is running, the second line of the Log file ends in “machine ”, so is that the EABI version?

Look for the “Built by” line on the about:testament page.

Is it possible to play MJPEG streams in Netsurf? Looks like it works with Iris and the old Firefox port.

Define MJPEG.

My video camera sends some sort of header followed by a series of JPEGs. VLC can cope with this.
My ESP32Cam sends a MIME separator followed by a JPEG, followed by MIME, followed by a JPEG, etc. The browser copes, VLC does not.
Then there’s MJPEG as a series of JPEGs wrapped in an AVI or MP4 or Matroska (etc etc etc) container.

So the first question – what exactly do you mean by MJPEG?

I never analysed my cameras mjpeg stream(s). Why I should?
I give the streamurl to ffplay, Iris or the very old Firefox and I see the video in realtime.
Is also possible via LTE on ARM- or Pinebook Pro. I have an open port and made a “camera web page” offert via HTTPServ. The stream will be played as an inframe.
Netsurf can handle inframe but not the stream.
I’m only user. Works or not is the question for me ;-)

P.S. VLC can handle the stream.

Please try out the new builds and let us know how you get on…..The NetSurf Developers

Running #5427 here on a Pi4/RO 5.29(04-Nov-21), and previously #5416, in both instances the ‘gnueabi’ version. No problems encountered, and as others have suggested, the new version seems a tad faster.

Camera: For a very short time you can try http://92.75.187.183:1080/

Where can I find FetchNS? Google draws a blank.

Searching on these forums I’ve posted the link before :)

I let fetch_ns by Frank de Bruijn do all the heavy-lift. The zipped NetSurf downloads are kept as backup and it automatically replaces the curren NS app.

https://aconet.nl/tools/#fetchns

HTH

I’ll see if I can find the time to add an option to Fetch_NS to pick up the new toolchain version.

Searching on these forums I’ve posted the link before :)

@David thanks, getting the name right Fetch_NS NOT FetchNS gets some Google hits.

New version of Fetch_NS

Add to Settings file:
Set Fetch_NS$NewToolchain 1

It seems to be stubbornly fetching the arm-unknown-riscos-gcc version, despite my attempts to configure it otherwise. I’m investigating further…

Edit: I’ve found and fixed my typo.

Curious that the LATEST file always references the unknown-riscos version, despite the Action and Fetch files referencing the wanted one.

And, importantly: thanks for your efforts, Frank.

Curious that the LATEST file always references the unknown-riscos version

That file is downloaded and stored unchanged, so we know what the site presented in case of errors. The ‘Fetch’ file shows what the code made of it, depending on the value of the Fetch_NS$NewToolchain variable.