Are we all doomed?

Any way to install in a different directory? Would it be a case of editing env.sh so it points elsewhere?

Either that or set TARGET_WORKSPACE.

Sounds like you didn’t set the TARGET_ABI to arm-unknown-riscos

Guilty as charged then it would seem, and twice at that!

The resultant build is now running on the Raspberry Pi.

Many thanks.

They’re the guides that I used to install the system.

Yep, but sometimes, Autobuilder is too complex for simple needs. I used to simply launch configure on the PC, then check the makefile and launch it with the GCC cross-compiler (and not the native one. Just by changing an environment variable). That was easy, and worked with many simple things (SDL games, CLI tools). Today, the process is more serious, but – IMHO – also too complex for small tasks.

Yep, but sometimes, Autobuilder is too complex for simple needs.

What autobuilder?

Well, I’ve just tried this and encountered some problems.

Firstly, step 2 (downloading and intalling the toolchain) will not work as it stands—since it installs into a subdirectory of /opt root privileges are required. If this really worked exactly as written then everybody who used it with no problems must be running as root—this is a bad idea!

I retried the command prefixed by sudo and continued. However, at the stage of building Netsurf I encountered some errors—as follows:

> make TARGET=riscos

/opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: 3: /opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: Syntax error: "(" unexpected (expecting ")")
/opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: 1: /opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: ELF????: not found
expr: syntax error
M.CONFIG: JPEG (libjpeg)	enabled       (NETSURF_USE_JPEG := YES)
M.CONFIG: PDF export (haru)	disabled      (NETSURF_USE_HARU_PDF := NO)
M.CONFIG: glibc internal iconv	enabled       (NETSURF_USE_LIBICONV_PLUG := YES)
PKG.CNFG: utf8proc (libutf8proc)	enabled
PKG.CNFG: nsutils (libnsutils)	enabled
M.CONFIG: SVG (libsvgtiny)	enabled       (NETSURF_USE_NSSVG := YES)
M.CONFIG: Drawfile rendering	enabled       (NETSURF_USE_DRAW := YES)
M.CONFIG: Sprite rendering	enabled       (NETSURF_USE_SPRITE := YES)
M.CONFIG: ArtWorks rendering	enabled       (NETSURF_USE_ARTWORKS := YES)
M.CONFIG: Drawfile export	enabled       (NETSURF_USE_DRAW_EXPORT := YES)
M.CONFIG: BMP (libnsbmp)	enabled       (NETSURF_USE_BMP := YES)
M.CONFIG: GIF (libnsgif)	enabled       (NETSURF_USE_GIF := YES)
M.CONFIG: PNG   (libpng)	enabled       (NETSURF_USE_PNG := YES)
M.CONFIG: JavaScript (mozjs185)	auto-disabled (NETSURF_USE_MOZJS := AUTO)
M.CONFIG: JavaScript (mozilla-js)	auto-enabled  (NETSURF_USE_JS := AUTO)
   MKDIR: build-Linux-riscos-elf
   MKDIR: build-Linux-riscos-elf/deps
TESTMENT: build-Linux-riscos-elf/testament.h
 GENBIND: javascript/jsapi/window.bnd
 GENBIND: javascript/jsapi/text.bnd
 GENBIND: javascript/jsapi/nodelist.bnd
 GENBIND: javascript/jsapi/node.bnd
 GENBIND: javascript/jsapi/navigator.bnd
 GENBIND: javascript/jsapi/location.bnd
 GENBIND: javascript/jsapi/htmlelement.bnd
 GENBIND: javascript/jsapi/htmldocument.bnd
 GENBIND: javascript/jsapi/htmlcollection.bnd
 GENBIND: javascript/jsapi/event.bnd
 GENBIND: javascript/jsapi/console.bnd
 GENBIND: javascript/jsapi/comment.bnd
MSGSPLIT: any/de to !NetSurf/Resources
MSGSPLIT: any/en to !NetSurf/Resources
MSGSPLIT: any/fr to !NetSurf/Resources
MSGSPLIT: any/it to !NetSurf/Resources
MSGSPLIT: any/nl to !NetSurf/Resources
 COMPILE: build-Linux-riscos-elf/comment.c
/opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: 3: /opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: Syntax error: "(" unexpected (expecting ")")
make: *** [build-Linux-riscos-elf/build-Linux-riscos-elf_comment.o] Error 2
> /opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: 1: /opt/netsurf/arm-unknown-riscos/cross/bin/arm-unknown-riscos-gcc: ELF????: not found

The last line is particularly unhelpful—but note that syntax errors are also reported.

For information, the commands I used were as follows.

wget <a href="http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh">http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh</a>
source env.sh
ns-package-install
wget <a href="http://ci.netsurf-browser.org/builds/toolchains/arm-unknown-riscos-2015-01-15_13-14-02.tar.xz">http://ci.netsurf-browser.org/builds/toolchains/arm-unknown-riscos-2015-01-15_13-14-02.tar.xz</a>
tar xvf arm-unknown-riscos-2015-01-15_13-14-02.tar.xz -C /
sudo tar xvf arm-unknown-riscos-2015-01-15_13-14-02.tar.xz -C /
TARGET_ABI=arm-unknown-riscos source env.sh
ns-clone
ns-pull-install
 
rm env.sh
cd ~/dev-netsurf/workspace
TARGET_ABI=arm-unknown-riscos source env.sh
cd netsurf
export PS1="> "
make TARGET=riscos

Firstly, step 2 (downloading and intalling the toolchain) will not work as it stands—since it installs into a subdirectory of /opt root privileges are required.

Please see the first paragraph of Rob’s guide (above the contents listing). There are other commands that must be run as root or with sudo too.

Edit: I’ve made the paragraph yellow and reformatted the text so its harder to miss.

Edit: I’ve made the paragraph yellow and reformatted the text so its harder to miss.

Yes, I noticed that and it does seem to be the nub of the matter. I had discovered that the tar instruction really did need to be sudo’d, obvious errors gave that away. However the two root requiring commands below were problematic, sudo fails and running without root privileges only does half a job, rufl goes missing here.

$ wget <a href="http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh">http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh</a>
# source env.sh
# ns-package-install

pittdj@iUbuntu1404:~$ wget <a href="http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh">http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh</a>
root@iUbuntu1404:/home/pittdj# sudo source env.sh
sudo: source: command not found
root@iUbuntu1404:/home/pittdj# sudo ns-package-install
sudo: ns-package-install: command not found

Using Ubuntu 14.04.2 LTS I found that enabling root login and using su in the terminal worked fully and allowed the build to complete.

pittdj@iUbuntu1404:~$ su
Password: 
root@iUbuntu1404:/home/pittdj# source env.sh
root@iUbuntu1404:/home/pittdj# ns-package-install
root@iUbuntu1404:/home/pittdj# exit
exit
pittdj@iUbuntu1404:~$ 

I hope this helps.

I missed that—sorry. Good idea to highlight these. Will try again tomorrow and report results. Seems the easiest way will be to have two terminals open, set in the appropriate directories.

BTW the recommended way for getting a root terminal in Ubuntu is NOT to enable root access but instead to use the command:

sudo bash

which is what I’ll try.

BTW I’m using Lubuntu 14.04 LTS.

They’re the guides that I used to install the system.

Yep, but sometimes, Autobuilder is too complex for simple needs.

Who mentioned using the Autobuilder? It’s certainly useful – for building things like NetSurf’s ported libraries, for example – but I don’t use it regularly.

ETA: When the Autobuilder is useful, it’s a lot less complex than doing things the “simple” way. :-)

I used to simply launch configure on the PC, then check the makefile and launch it with the GCC cross-compiler (and not the native one. Just by changing an environment variable). That was easy, and worked with many simple things (SDL games, CLI tools).

That’s precisely how it’s still done. My own (non-NetSurf) Makefiles contain the line

CC := $(wildcard $(GCCSDK_INSTALL_CROSSBIN)/*gcc)

to set $(CC) to the GCC cross-compiler. If there’s a need to be clever and target RISC OS and Linux in one project, then something like

ifeq ($(TARGET),riscos)
  CC := $(wildcard $(GCCSDK_INSTALL_CROSSBIN)/*gcc)
else
  CC := gcc
endif

will do it. In either case, compiling is then done by something like

$(CC) $(CCFLAGS) $(INCLUDES) $(LINKS) -o Executable,ff8 Source.c

(although I’ve missed out the object file stage for simplicity).

Today, the process is more serious, but – IMHO – also too complex for small tasks.

I’ve not looked at the new NetSurf build system that’s been presented here, as I still build it using the ‘old’ Cross-Build method that is more or less as described above. AIUI, I think the team have effectively standardised on the system used by their autobuild server (the one that spits out new test builds whenever changes are made to the codebase) – this makes a lot of sense in terms of ensuring that what the developers test is the same as what the beta-testers get from the test builds page. I don’t know how amenable it is to letting the system be used for other development work, however.

However the two root requiring commands below were problematic, sudo fails and running without root privileges only does half a job, rufl goes missing here.

No, those commands are just to `apt-get install` various standard Debian packages that you need. They have nothing to do with the NetSurf project libraries like rufl. Rufl gets installed later in the ns-clone and ns-pull-install steps (for which you need the TARGET_ABI set correctly for it to do the RISC OS specific ones like rufl).

That’s precisely how it’s still done. My own (non-NetSurf) Makefiles contain the line

Hum, I really should check that. The problem is that, now, I have really no interest any more in Linux. This solution would be just useful as a “make-some-ports” box.
Since Linux is needed for some projects, a ready to run image for RISC OS needs would be really great. ARM one if possible.

Back to the original post:

This also raises the question of who (if anyone) is assessing the impact of core changes on the RISC OS frontend. If the situation does not improve I shall be forced to remove RISC OS as a release architecture for subsequent releases.

While we do plan to release 3.3 for RISC OS, if the RISC OS front end does not get a maintainer we can’t just keep producing stable releases for the platform and hope it works.

I expect that we will continue to produce development builds of NetSurf after the release of 3.3, and ensure it continues to at least build for the foreseeable future. However, if the situation doesn’t change RISC OS won’t be getting a 3.4 release. The other platforms we release/don’t release for are all in the same boat; those that are developed get releases.

if the RISC OS front end does not get a maintainer

I would love to throw my name in the hat for this but fear I would not be suitable because:

a. I don’t have enough RISC OS programming experience
b. I may not have enough time to devote to it

But if nobody else comes forward then I’d be glad to help out where-ever possible.

Go for it Glen:-)
No one was born with any RISC OS experience and time is found by motivated people!
I’m sure you can rely on these forums for support and the previous maintainer may be able to help get you up to speed.

I have just tried to build NetSurf again but was not successful.

First I tried on my Mint computer and was met with all manner of strangeness – it seems that no matter what I did I could not get TARGET_WORKSPACE to point to my /data partition so I gave up and installed a fresh copy of the latest Debian in a virtual drive.

Leaving all the settings as default (i.e., building into the /home directory) I followed the commands on the guide (making sure to change to root where appropriate) and yet no matter what I do I can’t get it to build. Each time it fails because it can’t find rufl.h

When I type:

echo $TARGET_ABI

I just get a blank line so it seems that typing “TARGET_ABI=arm-unknown-riscos” is not actually setting the variable correctly – anyone have any ideas what might be going wrong?

I followed the commands on the guide (making sure to change to root where appropriate) and yet no matter what I do I can’t get it to build. Each time it fails because it can’t find rufl

I have found a little weirdness and to be honest don’t know what to make of it.

pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos source env.sh
BUILD=x86_64-linux-gnu
HOST=arm-unknown-riscos
TARGET_WORKSPACE=/home/pittdj/dev-netsurf/workspace
USE_CPUS=-j4
pittdj@iUbuntu1404:~$ echo $TARGET_ABI

pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos
pittdj@iUbuntu1404:~$ echo $TARGET_ABI
arm-unknown-riscos
pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos source env.sh
BUILD=x86_64-linux-gnu
HOST=arm-unknown-riscos
TARGET_WORKSPACE=/home/pittdj/dev-netsurf/workspace
USE_CPUS=-j4
pittdj@iUbuntu1404:~$ echo $TARGET_ABI
arm-unknown-riscos
pittdj@iUbuntu1404:~$ TARGET_ABI=nil
pittdj@iUbuntu1404:~$ echo $TARGET_ABI
nil
pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos source env.sh
BUILD=x86_64-linux-gnu
HOST=arm-unknown-riscos
TARGET_WORKSPACE=/home/pittdj/dev-netsurf/workspace
USE_CPUS=-j4
pittdj@iUbuntu1404:~$ echo $TARGET_ABI
nil
pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos
pittdj@iUbuntu1404:~$ echo $TARGET_ABI
arm-unknown-riscos
pittdj@iUbuntu1404:~$ 

The trailing source env.sh seems to be having some sort of effect.

If you run `FOO=bar cmd`, the FOO variable is only added to the environment of the cmd. There is no point in polluting the global environment with TARGET_ABI. The only thing that cares about it is the env.sh script. If you do want to want anything else to see TARGET_ABI (such as `echo`), then do `export TARGET_ABI=foo`.

pittdj@iUbuntu1404:~$ TARGET_ABI=arm-unknown-riscos source env.sh
BUILD=x86_64-linux-gnu
HOST=arm-unknown-riscos
TARGET_WORKSPACE=/home/pittdj/dev-netsurf/workspace
USE_CPUS=-j4
pittdj@iUbuntu1404:~$ echo $TARGET_ABI

What’s the problem? HOST is set, and TARGET_ABI isn’t leaked. Did the build not work? You said earlier:

The resultant build is now running on the Raspberry Pi.

I could not get TARGET_WORKSPACE to point to my /data partition

You did something like `export TARGET_WORKSPACE=/data/netsurf/workspace`? It should work.

Leaving all the settings as default (i.e., building into the /home directory) I followed the commands on the guide (making sure to change to root where appropriate) and yet no matter what I do I can’t get it to build. Each time it fails because it can’t find rufl.h

Please stick a copy of the terminal text (your commands and the resultant output) in a pasetbin somewhere (or paste in a post here if its not too much).

What’s the problem?

Me, probably. The apparent echo failure is a red herring.

Anyway, by way of penance, I have redone the whole build procedure on a new instance of Ubuntu 14.04.2 and it works.

You did something like `export TARGET_WORKSPACE=/data/netsurf/workspace`? It should work.

Yes I did, and yes it should! Like I said my Mint box has been acting a bit weird lately…

Please stick a copy of the terminal text (your commands and the resultant output) in a pasetbin somewhere (or paste in a post here if its not too much).

Will do. Just setting up a fresh virtual machine so I have a clean environment – also gives me another chance at getting it right!

I’m still having problems. I’ve tried repeating the procedure using root at the appropriate point but now get an error at an earlier stage of the process, specifically when using the command ns-pull-install:

    LINK: build-i686-linux-gnu-i686-linux-gnu-release-binary/nsgenbind
install  -m 755 build-i686-linux-gnu-i686-linux-gnu-release-binary/nsgenbind /home/davidg/dev-netsurf/workspace/inst-arm-unknown-riscos/bin
make: Leaving directory `/home/davidg/dev-netsurf/workspace/nsgenbind'
    MAKE: make -C libwapcaplet -j2 install
make: Entering directory `/home/davidg/dev-netsurf/workspace/libwapcaplet'
/home/davidg/dev-netsurf/workspace/inst-arm-unknown-riscos/share/netsurf-buildsystem/makefiles/Makefile.tools:383: *** Unable to detect toolchain. Stop.

Well it looks like the weak link in the chain was me.

My latest attempt worked just fine!

If anyone is interested in the output it is available here: Pastebin of konsole output

Now that I have a working build environment – what can I do to help?

You used Debian here? I’m going to try that next.

Yes it was Debian inside Virtual Box which was running on Mint. Couldn’t get it to work on Mint but its nicer to have it all contained in a virtual machine anyway (that way I can upgrade/change my Mint install and still have the same development environment).

Now that I have a working build environment – what can I do to help?

Try looking at the bugs which are open against the RISC OS front end. Maybe Steve can advise on the best place to start.