Python 3.8 - alpha release

The conflicts are probably because you updated the shared libraries from outside PackMan. To be safe you could make a copy of the whole !SharedLibs directory somewhere safe. Then let PackMan update them. Reboot and check everything is OK.

Have done as Alan suggested. Ie moved SharedLibs to safe place and installed new SharedLibs from PackMan.
Now !Python3 won’t run:-

SCSI::SSD.$.JR.Programz.PYTHON.!Python3.python3: can’t load library ‘libm.so.1’

… the last time I messed with SharedLibs it went badly wrong and I had to rebuild the whole system from scratch.

Beginning to recognize the contours of the familiar rabbit hole. We have got into a real mess with SharedLibs.

Beginning to recognize the contours of the foamiliar rabbit hole. We have got into a real mess with SharedLibs.

Well I’m not so sure as I have done the uninstall and reinstall of SharedLibs and Python 3.8 works here on ARMX6.

So perhaps something to do with your !Boot/set up?

Do you have !Iris/Pine Browser, !Otter or !Qupzilla being seen before Python 3.8 is loaded.

Easiest way is to do a Show *ShareLibs before running Python to see where SharedLibs is being seen /loaded from?

Is it where you have the Packman version of SharedLibs stored?

Have done as Alan suggested. Ie moved SharedLibs to safe place and installed new SharedLibs from PackMan.

What, exactly, did you install from PackMan? Python3 requires the SharedLibs, SharedUnixLibrary, SharedLibs-C2 and CryptRand packages to be installed.

We have got into a real mess with SharedLibs.

We have. I highlighted this before and had my wrist slapped, so I’ll comment no further.

and had my wrist slapped

But but but shared libraries are the future! They offer so much goodness and what’s the problem? Everybody else copes with DLL hell, why can’t we?

<stir> <stir>

What, exactly, did you install from PackMan? Python3 requires the SharedLibs, SharedUnixLibrary, SharedLibs-C2 and CryptRand packages to be installed.

Thanks for the hint Steve – I did not have SharedLibs-C2 or CryptRand.
They are now re-installed and – Python3 runs again.

However, trying to install pip fails as before with:-

*python3 -m pip install riscos_toolbox

[33mWARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.[0m

[33mWARNING: Retrying … after connection broken by ‘SSLError("Can’t connect to HTTPS URL because the SSL module is not available.")’: /simple/riscos-toolbox/[0m

An internet search shows that this is a common problem on other platforms but with no consensus on how to fix it.

pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available

The error message is misleading. The Python module is present at !Python3.Lib.ssl, what is missing is an ABI2.0 SSL Library in !SharedLibs, which can be found here.

*python3 -m pip install riscos_toolbox
Collecting riscos_toolbox
  Downloading riscos_toolbox-0.1.0-py3-none-any.whl (4.9 kB)
Installing collected packages: riscos-toolbox
Successfully installed riscos-toolbox-0-1-0
*

But but but shared libraries are the future

Are you sure about that? On Linux, there is an increasing trend to bundle the libraries up with the application in a “container”. Being Linux, there are three different ways—Snaps (mostly for Ubuntu, Canonical run the only “store”), Flatpaks, and AppImage.

Over on Windows, DLLs are always searched for first in the app’s own directory, so you can have multiple versions of the same library available. Yes, there are problems, but there is no trouble-free solution—unless you do what some Linux distros do, and issue only security updates—no new versions.

shared libraries are the future

Shared libraries surely were the future, long, long ago when memory was at a premium?

shared libraries are the future

Um, guys?

Woosh!

The Python module is present at !Python3.Lib.ssl, what is missing is an ABI2.0 SSL Library in !SharedLibs, which can be found here.

And which, given John’s problems which led us here, should probably be installed from within PackMan and not by downloading a package file and manually installing it.

ETA: The package name inside PackMan is “LibSSL”, I think.

Well I’m not so sure as I have done the uninstall and reinstall of SharedLibs and Python 3.8 works here on ARMX6.

OK I take it all back!

There is something wrong with Packman and the dependacies etc as I did another withdraw and install and also it asked me if I wanted to upgrade to the latest packages and also ARMEABISupport.

This time Python3 install of riscos_toolbox would not work and neither would Qupzilla or Otter load.

ARMX6 30th June 2020 ROM.

After much searching I found this issue mentioned:

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.

So I downgraded the mentioned libUnixLib/5/0/0/so file in SharedLibs and now Qupzilla, Otter and Python3 riscos_toolbox works.

As mentioned before “What a mess”

So I downgraded the mentioned libUnixLib/5/0/0/so file in SharedLibs and now Qupzilla, Otter and Python3 riscos_toolbox works.

+=1. I have a second !SharedLibs with the older libUnixLib/5/0/0/so for use with those older builds. It also has SOManager 2.10 so that otter-browser starts up first time. A reboot is required to swap between that and the primary, bang up to date, !SharedLibs.

As mentioned before “What a mess”

Not to mention what a time waster.

As far as I can see there have been recent fixes to UnixLib5 so presumably new builds with the current autobuilder or GCC 4.7.4 Release 4 should be OK. The runables and libraries would be compatible. Hopefully!

The error message is misleading. The Python module is present at !Python3.Lib.ssl, what is missing is an ABI2.0 SSL Library in !SharedLibs, which can be found here.

Thanks David – I merged the contents of your link with SharedLibs but got the same result – However, I noticed that PackMan was offering some updates so ran an update lists and an upgrade all and eh voila!

*python3 -m pip install riscos_toolbox
Collecting riscos_toolbox
Downloading riscos_toolbox-0.1.0-py3-none-any.whl (4.9 kB)
Installing collected packages: riscos-toolbox
Successfully installed riscos-toolbox-0-1-0
*

I merged the contents of your link with SharedLibs

No, do not do this. If SharedLibs was installed by PackMan as you say, install new libraries into it via PackMan too. The link that David gave was a PackMan package.

It’s manually merging in stuff that PackMan can manage itself which led to the conflicts originally. Don’t do it.

No, do not do this. If SharedLibs was installed by PackMan as you say, install new libraries into it via PackMan too. The link that David gave was a PackMan package.

I tried to do it via PackMa initially but it said it could not update because of conflicts with files. The files were the 6 files in the link.

I tried to do it via PackMa initially but it said it could not update because of conflicts with files.

Because you’ve manually installed them in the past… which is where we came in.

I think it’s time for me to package Python so you get it from PackMan, then it can get the dependancies itself.

I’ve had 3.8a6 working (and a5 before that) on my ARMx6 mini.m with RO 5.27 (09-Jun-20), but after a week or so during which time I’ve been updating various software, now I get:-

pthread_cond_init: Invalid argument
Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize threads for interpreter
Python runtime state: unknown

Any ideas?

Edit: The same copy via ShareFS is running ok on a Raspeberry Pi 3.

That will be the same issue i had with SharedLibs.

So I downgraded the mentioned libUnixLib/5/0/0/so file in SharedLibs and now Qupzilla, Otter and Python3 riscos_toolbox works.

So get an old copy of SharedLibs.lib.abi-20/0/libunixlib/5/0/0/so, no later than 13th Oct 2019, and the same file in the vpf folder and it should work.

You may find Otter and Qupzilla don’t work either until these files are updated.

As said before this has got in to a mess and then you create your own mess by manually updating to fix it!

Hopefully it will be sorted soon by the packaging team.

Finding where needed files come from would be easier if PackMan, like Synaptic which it is supposed to be based on, had a way of showing which files have been installed where. And things would be better if packages being added to PackMan were checked for compatibility before they were listed!

Downgrading to a libUnixLib/5/0/0/so from Oct 2012 fixed Python 3.8a6 – Thanks.

Not that worried about Otter or Qupzilla, as they are far too slow to be practical. I can switch the monitor to another computer, do a query and be back again before they have started!

Finding where needed files come from would be easier if PackMan…

PackMan development is slow and driven mainly by user feedback. The list of files does exist, there is just no UI in PackMan to show it. If it’s an import option that’s missing it can be added, it just needs a bit of communication with the author (me) and a lot of patience.

like Synaptic which it is supposed to be based on

Not sure where you got this idea from. PackMan is a front-end to LibPkg which used debian packages as inspiration for the package format. The PackMan UI started as an easier to use replacement to RiscPkg and has evolved over years due to user feedback.

I guess I should own up to one or two of the shared library issues here. The “pthread_cond_init – Invalid argument” was my cock up as I erroneously changed the code to reject a NULL attribute when in fact a NULL attribute indicates use default values. This is now fixed in Unixlib and I believe Alan is working on another update (Sorry Alan!).

But we’re not done yet. A subsequent crash in pthread_cond_signal is I believe due to me adding an extra member to __pthread_cond increasing its size. This will require a rebuild of python against the pthread.h from GCC release 4 (or later) so that the size it allocates to such an object matches those in Unixlib from GCC release 4.

The list of files does exist, there is just no UI in PackMan to show it.

It would be a useful feature to have sometime. The UI that Synaptic provides for this is simplistic—just a scrollable text box with a simple list of the full pathnames of the files. Alternatively, if there’s any way to see the list of files without going through the GUI?

The list of files does exist, there is just no UI in PackMan to show it.

It would be a useful feature to have sometime. The UI that Synaptic provides for this is simplistic—just a scrollable text box with a simple list of the full pathnames of the files.

I’ve added this to my list of things to do. Sorry I’ve no idea when I’ll do it though.

Alternatively, if there’s any way to see the list of files without going through the GUI?

The information for each package installed is stored at:

!Boot.Resources.!Packages.Info.<package_name>

In the directory is a file called “Files”. This gives a list of everything installed. It’s not quite as useful as a proper file list as it shows logical filenames rather than actual file names. You can look in the Advanced menu, Paths option to see the logical path to real path mappings.