Iris, Otter and Qupzilla

These browsers seem to interfere with each other: If one of them can’t crack a webpage and you try another it won’t load and there’s an error window. I have tried KillSOM, but this doesn’t always work. Of course, I can re-boot the computer; but is there a less drastic way?

The error windows say things like: “SOMrun not found” or can’t find one of those files in SharedLibs.

You should killSOM, than boot the right SharedLibs… and prey.
I hope, that soon the devs will agree on one toolchain, and provide new versions of Iris, Otter, Qupzilla and OWB.

The funny part, is that OWB and Qupzilla are the only one I can’t use, when the others are here… and the two ones I prefer :)

OWB crashes, but is so fast.
Qupzilla was much faster to boot on my computer than Otter.

Yes, I thought it was a ‘fight’ over SharedLibs. So I have run the SharedLibs in !Boot.Resources (a *show revealed that Iris had been using its own SharedLibs inside its directory) and Otter opened its home page; but, shock horror, the menus have no text! :-(
Right, it must be using its own UnixFont and UnixFC. Yes, sure enough it is. So, close Otter’s window, run UnixFont and UnixFC, fire up Otter and bingo, the menus have text! :-)
What a palava!

Iris and OWB aren’t on general release yet, and need newer versions of some libraries. No doubt these issues will be sorted out when they’re finished…

(Note: Windows looks for shared libraries first in the same directory as the relevant executable. Now you know why Microsoft did that. Looks like the browser issue is the RISC OS version of “DLL hell” — there are similar issues on all systems that use shared libraries—on many Linux distros, you only ever get security updates, not new versions.)

Oh, it gets worse, Iris runs its own version of Reporter. I run Reporter from computer bootup and I have often noticed that when Iris crashes, or maybe after closing it, the Reporter window has vanished. I had noticed a copy of Reporter inside the Iris dirctory before, but wondered whether I had accidentally copied the application into it – easily done in RISC OS – or whether it was meant to be there for reporting Iris errors. What more is in Iris?

To the 2 Davids thanks for your replies. Oh, we are all 3 Davids! It’s a bit like there being several SharedLibs, UnixFCs UnixFonts.

Right, I am looking at this more systematically. Iris has its own versions of CaCertificates, Reporter, UnixFC, UnixFont, Clipboard, CryptRand, SharedULib and SharedLibs. Any more? I am a mere user, but this aspect of Linux and, more generally, OSs that use shared libraries, looks a complete mess to me.

several SharedLibs, UnixFCs UnixFonts.

If it is really neccessary to do this it may be worth unsetting the system variables at the start up of each instance.
Something like Unset SharedL* and Unset UnixF* might do it.
You possibly will have to follow that up by running the required SharedLibs etc.
Filer_Run <Obey$Dir>.This.apps.!SharedLibs
You can also help keep Applications hidden by burying them and run them by way of !Launcher with the filer_boot option off.
Moving the setting of variables from an apps !Boot to !Run is another way (until it is actually run)

Neither !Otter-browser nor !QupZilla start here if SOManager 3.01 is loaded but both are fine with SOManager 2.10.

*fx0
RISC OS 5.27 (23 Jun 2020)
*help SOManager
==> Help on keyword SOManager
Module is: Shared Object Manager   3.01 (22 Jun 2020) (c) GCCSDK Developers

Otter-browser :-

*where
Address &222CEFDC is at offset &022CEFDC in dynamic area 'Module area'
*showregs
Register dump (stored at &2007A9F0) is:
R0  = 20002344 R1  = 51A921D8 R2  = AE56DE8C R3  = 51569000
R4  = 51569000 R5  = 51460570 R6  = D1460571 R7  = 205B2808
R8  = 51A921D8 R9  = 60000113 R10 = 00000000 R11 = 205B2820
R12 = 205B239A R13 = FA207F60 R14 = 205B2608 R15 = 222CEFDC
Mode SVC32 flags set: NzcVQjggggeAift        PSR = 98000113
*somaddress pc
Address 222cefdc is not known to the Shared Object Manager

QupZilla :-

*where
Address &20525FB0 is at offset &0000445C in module 'SOManager'
*showregs
Register dump (stored at &2007A9F0) is:
R0  = 00000000 R1  = 00000002 R2  = 4726BC40 R3  = 47369000
R4  = 47369000 R5  = 47260520 R6  = 205297D4 R7  = 010075C8
R8  = FFFBEEB8 R9  = 00000000 R10 = FA20021C R11 = FA207F98
R12 = 47260140 R13 = FA207F64 R14 = 20524C90 R15 = 20525FB0
Mode SVC32 flags set: nZCvqjggggeaift        PSR = 60000013
*somaddress pc
Address 20525fb0 is not known to the Shared Object Manager

Another David! That’s 4 of us so far. Thanks for reply, Ronald, but you are the odd man out in this thread. :-)
Would any other Davids like to contribute? Maybe we can set a record.

My ARMX6 has SOManager version 3.01 inside Iris’s SharedLibs and version 2.10 inside !Boot’s SharedLibs.

I see that Iris runs its version 2.66d of Reporter; but, as I said above, I have version 2.71 running from computer bootup to shutdown. From Iris’s run file it looks as if it runs its Reporter and closes the other one. I haven’t noticed this when running Iris as I rarely look at the Reporter window, but I notice it after Iris is closed. I would prefer not to have Iris’s version running, but continue with the other version. So, I could comment out the lines in Iris’s run file referring to Reporter. Would that do?
Can’t stop now, got to get out!

I was not aware that Reporter was ‘bundled’ with anything. And Reporter v2.66d is only about 8 years old, and a beta version at that! It should not be there!! It is also very bad manners to close a running Reporter, particularly to start an older version. v2.71 is the latest released version, and any problems with that can be reported to me. I do not have Iris, but would appreciate a pm with the authors contact details.

Sorry to be break the line of David’s in this thread! Andrew Rawnsley in another thread has already explained this issue which is known. RO Developments are trying to come up with a way to avoid this issue for the general release of Iris and OWB. All current versions that some lucky people have are beta so not in final versions. Conflicts with SOManager between browsers is one of those known issues. The SharedLibs seems to be the bigge issue, due to the older browsers like Otter and qupZilla needed some older SharedLibs lots of extras (files), and the newer browser requiring newer versions of SharedLibs because they use newer resources. Apparently this appears to going to be an issue going forwards for possibly other programs ported from other platforms.

Regarding the issue with Reporter, you could try commenting the version out in Iris and see what happens, you can always turn it back on if necessary.

Martin re the “bundled” version of Reporter, talk to RISCOS Developments, but its likely it there in the BETA version of Iris, so users can log faults and report them back. The version of reporter within Iris could simply be replaced with the newer version, or the Iris Run file changed to point to the users normal copy of !Reporter. AFAIK it not intended to be in the final public release of Iris

This does indeed sound like the issues Andrew posted about a few weeks ago.

It sounded like he was trying to distribute the betas as a simple standalone application with no external dependencies, and some of those dependencies may not yet be publically released. Awkward. But surely the simple solution is to get the libraries released publically first, then the browser. And do so with a package manager, so people don’t have to faff about.

Neither !Otter-browser nor !QupZilla start here if SOManager 3.01 is loaded but both are fine with SOManager 2.10.

In fact the latest Otter comes with libraries incompatible with Qupzilla :(

But surely the simple solution is to get the libraries released publically first, then the browser. And do so with a package manager, so people don’t have to faff about.

Or to cheat with a SOManager2, SOManager3, etc. with their own memory spaces.
Because the problem with the current way to do it, is that once we will jump to the last SOManager, a lot of old software will not work any more.

In fact the latest Otter comes with libraries incompatible with Qupzilla :(

That is not the case here, both QupZilla 1/8/9-2 and otter-browser 200520 run with the SharedLibs from the otter-browser zip :)

Both browsers are currently on the Titanium desktop. The only requirement is SOManager 2.10.

I would have tried builds of both browsers from current autobuilder sources but neither build. There have been UnixLib bug fixes, maybe there was a bug in the works. Clutching at straws perhaps but worth a try?

once we will jump to the last SOManager, a lot of old software will not work any more.

It would only be software that uses SharedLibs?

GCC4 Release 4 (pending) does build with SOManager 3.01, which it does not need for itself but is required for armeabihf builds such as Iris and GCC8.

That is not the case here, both QupZilla 1/8/9-2 and otter-browser 200520 run with the SharedLibs from the otter-browser zip :)

Really? I even try a clean install of the latest Otter… and I still get some errors with Qupzilla.
I’ll try again later.

Qupzilla and Otter Browser both work fine with the latest SOmanager 3.0.1 here. There was an abort on startup which required running again to get going. This no longer happens since the 2nd July RISC OS rom update.

 ARMEABISupport  1.00 (10 Apr 2020) (c) GCCSDK Developers
Shared Object Manager   3.01 (10 Apr 2020) (c) GCCSDK Developers
SharedUnixLibrary       1.16 (3 Apr 2020) (C) UnixLib Developers, 2001-2020

Qupzilla and Otter Browser both work fine with the latest SOmanager 3.0.1 here.

I’m not quite so lucky here on the Titanium and RPi4 with the latest ROMs. Otter-browser still crashes on first startup but on the second attempt it quits when the startup banner closes. QupZilla also quits when the start up banner closes but obliges with debug info.

SharedUnixLibrary       1.16 (3 Apr 2020) (C) UnixLib Developers, 2001-2020
Shared Object Manager   3.01 (24 Jun 2020) (c) GCCSDK Developers
ARMEABISupport  1.00 (24 Jun 2020) (c) GCCSDK Developers

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x91054 (Main Thread)
  ( 1007f34) pc: 4ccd275c lr: 4ccd2c3c sp:  1007f38  __write_backtrace()
  ( 1007fa0) pc: 4ccd2970 lr: 4ccd47d4 sp:  1007fa4  __unixlib_raise_signal()
  ( 1007fb0) pc: 4ccd46bc lr: 4cce06f0 sp:  1006d7c  __h_cback()

  Register dump at 01007fb4:

    a1:   1cd150 a2:        0 a3:       29 a4:        0
    v1:    714bc v2:        8 v3:    7bbc8 v4:        0
    v5:   1cd148 v6:    88944 sl:   f07208 fp:  1006da0
    ip:    93ef8 sp:  1006d7c lr: 4cce06f0 pc: 4c728f8c
    cpsr: 20000010

  4c728f78 : x@î : e5944078 : LDR     R4,[R4,#120]
  4c728f7c : ~Ì˛Î : ebfeed7e : BL      &4C6E457C
  4c728f80 : ..†„ : e3a01000 : MOV     R1,#0
  4c728f84 : ..ÖÂ : e5850000 : STR     R0,[R5,#0]
  4c728f88 : y◊˛Î : ebfed779 : BL      &4C6DED74
  4c728f8c : \0ü : e59f305c : LDR     R3,&4C728FF0
  4c728f90 : .`îÁ : e7946003 : LDR     R6,[R4,R3]
  4c728f94 : X0ü : e59f3058 : LDR     R3,&4C728FF4
  4c728f98 : ..†· : e1a01006 : MOV     R1,R6

  ( 1006da0) pc: 4c728f5c lr: 4c71e9f8 sp:  1006da4  QWaitCondition::QWaitCondition()
  ( 1006dc0) pc: 4c71e9c0 lr: 4c9b5e3c sp:  1006dc4  QReadWriteLock::QReadWriteLock(QReadWriteLock::RecursionMode)
  ( 1006ddc) pc: 4c9b5dd4 lr: 4c9bd070 sp:  1006de0  QCoreGlobalData::instance()
  ( 1006df8) pc: 4c9bd058 lr: 4c7c3f3c sp:  1006dfc  QTextCodec::codecForLocale()
  ( 1006e18) pc: 4c7c3ef4 lr: 4c8ccd54 sp:  1006e1c  QString::fromLocal8Bit_helper(char const*, int)
  ( 1006e3c) pc: 4c8ccce4 lr: 4c835748 sp:  1006e40  QFileSystemEngine::homePath()
  ( 1006e50) pc: 4c835738 lr: 4ce54640 sp:  1006e54  QDir::homePath()
  ( 1006e6c) pc: 4ce5461c lr: 4d0cdc84 sp:  1006e70  _GLOBAL__sub_I_webpage.cpp()
  ( 1006e80) pc: 4d0cdc54 lr: 4ce30c30 sp:  1006e84  __do_global_ctors_aux()
  ( 1006eb0) pc: 4ce30c28 lr: 47364f3c sp:  1006eb4  ?()
  ( 1006ed4) pc: 47364d68 lr: 4cce9508 sp:  1006ed8  _dl_call_ctors()
  

( 1006da0) pc: 4c728f5c lr: 4c71e9f8 sp: 1006da4 QWaitCondition::QWaitCondition()
( 1006dc0) pc: 4c71e9c0 lr: 4c9b5e3c sp: 1006dc4 QReadWriteLock::QReadWriteLock(QReadWriteLock::RecursionMode

I get a similar error if I update to the latest libUnixLib/5/0/0/so Shared library. The one in the otter-browser.zip is dated 13 Oct 2019. Any later and it causes a crash on start up.

I get a similar error if I update to the latest libUnixLib/5/0/0/so Shared library. The one in the otter-browser.zip is dated 13 Oct 2019.

It is not in the otter-browser zip, 20/05/2020, at https://www.riscosports.co.uk/vfp/

The only earlier version I could find here was from 2017, and it didn’t work.

The path to the file in otter-browser.zip is
!Boot.Resources.!SharedLibs.lib.abi-2/0.vfp.libunixlib/5/0/0/so.

lib.abi-2/0.vfp.libunixlib/5/0/0/so

Thanks, guess who was looking in AB1-2/0.

QupZilla now starts fully first time but Otter-browser only on the second attempt.

Thanks again.

Shared Object Manager 3.01 (10 Apr 2020) © GCCSDK Developers
ARMEABISupport 1.00 (10 Apr 2020) © GCCSDK Developers

Shared Object Manager 3.01 (24 Jun 2020) © GCCSDK Developers
ARMEABISupport 1.00 (24 Jun 2020) © GCCSDK Developers

Oh great, same version number but different dates :-(

Probably just means that they are functionally equivalent albeit compiled at different times. (At least by intention.)

Something must have changed on my ARMX6 because now Otter throws an error on attempting to run it: Can’t load library libWebKit1.so.1 – why ever not?

The file libWebKit1/so/1 is present in !SharedLibs.lib.abi-2/0.vfp along with libWebKit1/so , if that’s relevant – they are identical.