sox update?

The version of ‘sox’ that I have on my ARMX6 is dated 2012. I’m hoping there is a newer version. But if so, where to find it? I know that – somewhere – there is a list of ported software as I’ve used it in the past. But I can’t recall where it is! So can someone please point me at this?

Ta!

Jim

There is a version of sox at riscosports.co.uk → https://www.riscosports.co.uk/eabi/

Thanks, that may be the repo I had in mind.

However having fetched it, I now seem to have a problem having it run!

I’ll play with it a bit.

You can not use sox “elf” outside the “app”. Let the filer see it or doubleclick if the older was seen before…
Than use the commandline as you know it.

When I try to use it, it just tells me “SWI &59D03 not known”!

I’m using an R-Comp version of the OS for my ARMX6.

Yes, I’ve tried using it as an app. Same result.

Just tried a reboot, then double-clicked on the app. Then tried a sox command. Same failure result. Am I doing something daft?

Needs an installed ARMEABISupport e.g. from PackMan.

The easiest thing to do is install SharedLibs using PackMan. It will install all the needed dependencies.

That prompts two questions:

1) I already have a !SharedLibs. Is there a risk that updating will break anything else?

2) Shouldn’t the app give a user-recognisable explanation of this? As it stands it just specifies a swi is AWOL without any message that would point the user in the right direction. I associate a ‘missing swi’ with having a missing or too-old module. But the app give me no clue. as it doesn’t RMEnsure, or give a meaningful message for normal users.

1) I already have a !SharedLibs. Is there a risk that updating will break anything else?

SharedLibs needs to be updated to the latest version to enable EABI ELF executables to load.

2) Shouldn’t the app give a user-recognisable explanation of this? As it stands it just specifies a swi is AWOL

The ARMEABISupport module is loaded by the latest SharedLibs the first time it is seen by the filer.

I’ll give it a go. But the above doesn’t actually answer my questions. :-)

But the app give me no clue. as it doesn’t RMEnsure, or give a meaningful message for normal users.

The app should RMEnsure and give a proper error message that suggests what you need to do. You are right.

Not yet ‘updated’ !PackMan for two reasons.

1) I don’t have a previous version installed anyway! Although I DO have !Packages. And some programs that use the relevant resources.

2) There is a thread in csaa at present where !PackMan has apparently fouled up something that had been working, or at least this is suspected.

Yes, I’ve tried using !Locate to find !PackMan on my machine. No sech animal! finds !Packages OK, though.

A non-eabi, or ‘ordinary’, sox is here

Both variants are from the same version of sox, 14.4.2. The eabi build will be faster and does require the current eabi aware SharedLibs.

HTH.

Not yet ‘updated’ !PackMan for two reasons.

1) I don’t have a previous version installed anyway! Although I DO have !Packages. And some programs that use the relevant resources.

I’ve posted to announce this week if you want to get the latest version.

2) There is a thread in csaa at present where !PackMan has apparently fouled up something that had been working, or at least this is suspected.

I couldn’t find this thread. What was the problem?

Yes, I’ve tried using !Locate to find !PackMan on my machine. No sech animal! finds !Packages OK, though.

That just means you’ve deleted !PackMan or used !RiscPkg in the past.

I couldn’t find this thread. What was the problem?

It’s to do with embedding the !ShareLibs folder inside the application folder which normally causes more problems than it solves.
If Packman comes along and installs !SharedLibs into Boot:Resources things then start to break as you can’t have more than one !ShareLibs folder active at the same time. Especially if the embedded !SharedLibs is using an older version than the one PackMan installs.
Only !SharedLibs Rel5 is guaranteed to work with FPA, VFP and EABI ELF shared libraries and ELF statically linked executables

As long as SharedLibs is maintained by PackMan then everything just works.

I couldn’t find this thread. What was the problem?

It’s the response to your csa.announce post about PackMan 0.9.7, in csa.apps. User updates PackMan and some other bits, and problems were reported with conflicts in !Boot… later, “OBrowser from R-Comp” doesn’t work, and owner can’t find the “R-Comp install CD” to fix it.

It’s to do with embedding the !ShareLibs folder inside the application folder which normally causes more problems than it solves… As long as SharedLibs is maintained by PackMan then everything just works.

Sadly, we’re still having arguments here about why it should be OK to distribute SharedLibs on an install CD without making any effort for that CD to install via a Packman-friendly process.

Using !Locate, I found where my copy of !Packages may have come from. It was included in an ARMiniX update some time ago. I presume that ended up being transferred to my ARMX6. !Locate finds no sign of !PackMan on my ARMX6 and I have no recollection of ever installing and then removing it for any reason.

So I’ve just used the other version of sox that David gave me the URL for. That seems to be the place where I’ve got other items in the past.

Given all the above I remain wary of breaking something else.

Sadly, we’re still having arguments here about why it should be OK to distribute SharedLibs on an install CD without making any effort for that CD to install via a Packman-friendly process.

Just to mention, !Obrowser from R-Comp does NOT have !SharedLibs within the application, If I remeber correctly since its sometime ago when I installed it, it provided an installer to update !SharedLibs with !Boot.Resources There is a Text file with !Obrowser’s Resources folder which seems to list the !SharedLib files it needs/wants/expects.

Personally I don’t trust Packman to install things correctly. It removed things it plainly should not have done in the past, so if I must use it I take a big backup of everything before I use Packman – Sorry Alan. Just noticed in my copy of Packman 0.9.5 the Help option on the application icon bar menu seems to be broken.

If I remeber correctly since its sometime ago when I installed it, it provided an installer to update !SharedLibs with !Boot.Resources There is a Text file with !Obrowser’s Resources folder which seems to list the !SharedLib files it needs/wants/expects.

Does it check for a package database and, if one is present, update it appropriately so that any package managers (Packman or otherwise) know about the updates?

Personally I don’t trust Packman to install things correctly. It removed things it plainly should not have done in the past, […]

Whilst I’m sure that bug reports would be appreciated (did you?), I could hazard a guess that this isn’t entirely unrelated to the paragraph above…

Does it check for a package database and, if one is present, update it appropriately so that any package managers (Packman or otherwise) know about the updates?

Not that I am aware of and personally I would not expect it too. I think it been mentioned before the package management system is not the traditional way, RISC OS users have installed software. As I have said above, I simply don’t trust Packman, certainly in how it works now, I don’t think I am the only one.

Whilst I’m sure that bug reports would be appreciated (did you?), I could hazard a guess that this isn’t entirely unrelated to the paragraph above…

To be quite honest I cannot remember if I reported it directly or as part of thread where others had a similar issue.

I think it been mentioned before the package management system is not the traditional way, RISC OS users have installed software.

Is that from a time when software was distributed on floppy disc and Web browsers didn’t exist.

Just to mention, !Obrowser from R-Comp does NOT have !SharedLibs within the application

It looks like there are two versions of !Obrowser in existence. One where everything is embedded in the application folder and one that has an installer.

Sadly, we’re still having arguments here about why it should be OK to distribute SharedLibs on an install CD without making any effort for that CD to install via a Packman-friendly process

I think Andrew made the point about some software being Beta and not wishing to “alter” someones set up that may cause issues and given the feedback here I can see why even though I may not entirely agree with it.

Personally I don’t trust Packman to install things correctly.

I think the issue really comes down to mixing self installed and uniquely set up stuff and just letting a package manager do everything. If you mix the two then it can cause issues but is that a fault with Packman if someone installs via it first then tinkers with that install and wonders why an update fails?

As long as people understand what they gain and what they lose by using Packman and adhering to guidelines then it works but if you take a “free” spirit approach then may be leave alone but don’t slate Packman because you like that freer choice.

Both ways have pro’s and con’s hence why we have so many help requests here and else where.