Pygame error can't resolve symbol

Recently two Python3/Pygame games were released. Please see https://www.riscository.com/2021/code-the-classics-boing-myriapod/ for details. An ARMX6 user has reported back that both games as well as the example programs delivered with the RO Pygame version 1.9.6 are failing to run on his system. We have established that:
1) all steps as documented with the game have been followed:
installation of Python-38, Python-38-pip, Python-38-pygame, Python-Core
installation of additional libraries as kindly shared in a previous post by Chris Gransden:
- LibFreeType6
- LibOgg
- LibVorbis
- LibFlac
- Tremor
- LibPNG16-16
- LibTIFF5
- LibSDL1.2
- LibSDLImage1.2
- LibMikMod
- LibSDLMixer1.2
- LibSDLTTF2
- as well as TaskRunner
2) the Iris webbrowser is installed, but is not running when Python 3 / Pygame are being run
Nevertheless, whenever a pygame program is being run the same error below is given. Even for a basic program like below which opens only a window in the desktop.

Program Pygame Window:
import pygame

WIDTH = 480
HEIGHT = 480
FPS = 60

screen = pygame.display.set_mode((WIDTH, HEIGHT))
pygame.display.set_caption(“Pygame Window”)
clock = pygame.time.Clock()

running = True
while running:
clock.tick(FPS)
for event in pygame.event.get():
if event.type == pygame.QUIT:
running = False
elif event.type == pygame.KEYDOWN:
if event.key == pygame.K_ESCAPE:
running = False

pygame.quit()

Error:
SCSI::SSD.$.Apps.Development.!Python3.Bin.python38: can’t resolve symbol ‘pthread_condattr_setclock’
SCSI::SSD.$.Apps.Development.!Python3.Bin.python38: can’t resolve symbol ‘inflateValidate’
Fatal Python error: (pygame parachute) Segmentation Fault
Python runtime state: initialized

Current thread 0×00299d80 (most recent call first):
File “frozen importlib._bootstrap”, line 219 in call_with_frames_removed
File “frozen importlib._bootstrap_external”, line 1153 in create_module
File “frozen importlib._bootstrap”, line 556 in module_from_spec
File "frozen importlib.bootstrap", line 657 in load_unlocked
File "frozen importlib.bootstrap", line 975 in find_and_load_unlocked
File "frozen importlib.bootstrap", line 991 in find_and_load
File "frozen importlib.bootstrap", line 219 in call_with_frames_removed
File “frozen importlib._bootstrap_external”, line 1153 in create_module
File “frozen importlib._bootstrap”, line 556 in module_from_spec
File "frozen importlib.bootstrap", line 657 in load_unlocked
File "frozen importlib.bootstrap", line 975 in find_and_load_unlocked
File "frozen importlib.bootstrap", line 991 in find_and_load
File "SCSI::SSD.$.PythonSite.Python38.Site-Packages.pygame._init__", line 167 in
File “frozen importlib._bootstrap”, line 219 in call_with_frames_removed
File “frozen importlib._bootstrap_external”, line 827 in exec_module
File "frozen importlib.bootstrap", line 671 in load_unlocked
File "frozen importlib.bootstrap", line 975 in find_and_load_unlocked
File "frozen importlib.bootstrap", line 991 in _find_and_load
File “Myriapodpy$Dir.main/py”, line 3 in module

Does anyone have any idea what might be going wrong here?

SCSI::SSD.$.Apps.Development.!Python3.Bin.python38: can’t resolve symbol ‘pthread_condattr_setclock’

That error indicates that !SharedLibs has not been updated to the latest version. Currently Release 5.

Easiest thing to do is create a ‘PackMan’ package for each Pygame game which can install all the required dependencies automatically.

2) the Iris webbrowser is installed, but is not running when Python 3 / Pygame are being run

That error indicates that !SharedLibs has not been updated to the latest version. Currently Release 5.

Perhaps !Iris is being seen and it’s SharedLibs now added in to the equation?

*show *sharedlibs* 

should see what SharedLibs is being looked at.

Both games work on my ARMX6 with the added libraries that Chris mentioned.

Perhaps !Iris is being seen and it’s SharedLibs now added in to the equation?

The error is to do with the version of !SharedLibs not being up to date. Python3 or anything that uses !SharedLibs wont run at all if !Iris has been run. It’s possible to merge the ‘fake’ !ShareLibs in !Iris with the real one so everything can co-exist.

Both games work on my ARMX6 with the added libraries that Chris mentioned.

Ditto on my ARMX6. Boing stutters occasionaly and the bat misses the ball, but Myriapod works smoothly.

It is disappointing that Iris still trashes Sharedlibs. I test new versions of Iris as they appear then lock it away until the next release.
RComp should treat this problem as top priority, It is more important than the minor improvments that make up most releases.

RComp should treat this problem as top priority

A solution already exists.

It’s straight forward to manually move the required files to the correct locations. Also a couple of lines need commenting out in the !Run file.

A solution already exists.

Perhaps, but your response is cryptic.
I am not sure how !Packit will help as Iris is provided as a zip file and is not packaged for install via PackMan.

Are you suggesting I change the Iris !Run file also?

John Rickman, I don’t have this issue with the !SharedLibs and other programs while Iris is in use. I solved it by Running !Iris at computer startup and before other programs like Sargasso which uses !SharedLibs. I get no objections then from other programs.

ROD have already indicated that the version of !SharedLibs within !Iris is general using the latest cutting edge version of the !SharedLibs files, the Iris programmer now believes, that are fairly stable for more general use.

I don’t have this issue with the !SharedLibs and other programs while Iris is in use. I solved it by Running !Iris at computer startup and before other programs like Sargasso which uses !SharedLibs. I get no objections then from other programs.

Chris – have you tried to run Python38? I believe you will find that it does not work if !SharedLibs has been set by !Iris.

As has been suggested it is possible to merge the standard !SharedLibs with the experimental !Iris version so that !Python38 and !Iris can coexist. This is not a satisfactory solution as it messes with !PackMan installed components, I’ve been there and been bitten and am not keen to do it again.
RComp created this problem. They develop !Iris and funded, or partially funded python3, so they should solve it as a matter of urgency and certainly before !Iris is released more widely. I have spoken to Andrew about this on a number of occasions but my request has so far fallen on deaf ears.

As has been suggested it is possible to merge the standard !SharedLibs with the experimental !Iris version so that !Python38 and !Iris can coexist. This is not a satisfactory solution as it messes with !PackMan installed components, I’ve been there and been bitten and am not keen to do it again.

I don’t trust !Packman, I was encourged to use it, by some on these forums, so I did, and quickly regreted it, it messed my machine up. In fact it was trying to install !Python 38 and its !SharedLibs that caused me grief. This was before I was using !Iris in earnest, luckly I had done a manual backup of my !SharedLibs before I let !Packman loose on it.

As I understand it some of the SharedLibs files are more upto date in !Iris anyway.

RComp created this problem. They develop !Iris and funded, or partially funded python3, so they should solve it as a matter of urgency and certainly before !Iris is released more widely. I have spoken to Andrew about this on a number of occasions but my request has so far fallen on deaf ears.

Just to correct a minor point, its not RComp that have been getting !Iris developed, but RISCOS Developments Ltd, who happen to share a Director (Andrew). As I have said in my previous post the programmer doing the work on !Iris, has been updating the !SharedLibs files to work with !Iris, but he now believes, they are now stable enough to be made the current standard version, but I know Andrew is still concerned that !Iris is still technically a beta release. So worried about allowing the version of !SharedLibs within !Iris to be on general release. Its a chicken and egg situation. You can not win. Personally I think it time to bit the bullett and release the version in !Iris as a merge to the one in !Boot.Resources. But to do that !Packman must be updated with the latest !SharedLibs resources to prevent a downgrade.

I don’t trust !Packman, I was encourged to use it, by some on these forums, so I did, and quickly regreted it, it messed my machine up. In fact it was trying to install !Python 38 and its !SharedLibs that caused me grief.

I would guess that as you had manually installed versions already that then trying to integrate those with the packaged versions most likely caused the issue.

Package management is great if you start from a clean slate and use it without then also using the RISC OS tinkering we have all got accustomed to.

!Iris is still technically a beta release.

And that Chris is the point many are not getting as if you are running Iris then you are now in the realms of being a beta tester with all that it entails just like if you install the latest overnight ROOL builds.

My moto is beta tester be aware as it may have unexpected issues but don’t blame the software it it causes you major problems as you should accept the risks.

I use Iris on the basis that if it is run I then reset the !SharedLibs paths if I want to use other Sharedlibs reliant software.

As the saying goes “You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time”

So lets end on the positive that at last we have a very capable browser that is near production ready status and thats what we should be rejoicing.

would guess that as you had manually installed versions already that then trying to integrate those with the packaged versions most likely caused the issue.

If PackMan finds existing files it will prompt to back them up and then continue as normal.

Package management is great if you start from a clean slate and use it without then also using the RISC OS tinkering we have all got accustomed to.

You don’t need to start from a clean slate.

My moto is beta tester be aware as it may have unexpected issues but don?t blame the software it it causes you major problems as you should accept the risks.

Beta software should be feature complete. Installing !Iris still breaks an existing install of !SharedLibs. Sounds like the installation process is ‘alpha’.

I would guess that as you had manually installed versions already that then trying to integrate those with the packaged versions most likely caused the issue.??

Possibly, I think the only updates done previously were for Sargasso.

Package management is great if you start from a clean slate and use it without then also using the RISC OS tinkering we have all got accustomed to.

You are probably right on this.

And that Chris is the point many are not getting as if you are running Iris then you are now in the realms of being a beta tester with all that it entails just like if you install the latest overnight ROOL builds.

Agreed.

So lets end on the positive that at last we have a very capable browser that is near production ready status and thats what we should be rejoicing.

Again agreed

If PackMan finds existing files it will prompt to back them up and then continue as normal.

That is not my experience when I have tried using it. But might have another go, when I have the time to test.

Beta software should be feature complete. Installing !Iris still breaks an existing install of !SharedLibs.

We are going to have to disagree on this. All software is in effect ‘beta’ to some degree.

We are going to have to disagree on this. All software is in effect ?beta? to some degree.

It shouldn’t be used as an excuse to deliberately break other software.

I have just used !Packman to install a program called Yassa – its a slideshow application, does not tell me where it is installing the software, just found it now buried in the Apps folder within another folder, which is not visible if you just click on the App icon on the icon bar, so I have no control over where the software ends up.

I have just used !Packman to install a program called Yassa ? its a slideshow application, does not tell me where it is installing the software, just found it now buried in the Apps folder within another folder, which is not visible if you just click on the App icon on the icon bar, so I have no control over where the software ends up.

If there is a triangle with a question mark next to the entry it means it’s built with an earlier version of the RsicPkg standard. There is no components file in the Yassa package so it’s not possible to move it at installion.
The section name governs where it gets installed. In this case $.Apps.Graphics.

So… y’all are using an early pre-release test version of a new browser which is considered “beta” and may have some issues…

…and you’re complaining that it has issues?

The mucking with SharedLibs is unfortunate, but known. You’ll need to work around it or accept that it is – in its current state – not suitable for your own particular system. I can imagine the priority is on getting the browser part working. Having the libraries play nice will follow.

If there is a triangle with a question mark next to the entry it means it?s built with an earlier version of the RsicPkg standard. There is no components file in the Yassa package so it?s not possible to move it at installion.?The section name governs where it gets installed. In this case $.Apps.Graphics.

Thanks for that information, so that is what the triangle meant, I thought it was to do with compatibility.

Well two of the SharedLibs options I can see in !Packman, have the triange and two do not. So not exactly encourging for installing. This is a clear example of why I have issues with !Packman

If PackMan finds existing files it will prompt to back them up and then continue as normal.

When I did an install over an existing manually installed SharedLibs it did do that and then RISC OS being robust bailed out on the boot sequence, on next reboot, as it saw the backed up files within SharedLibs and halted the boot sequence.

Deleteing the backed up directory within SharedLibs cleared the issue.

To be clear I think Packman and packaged managed software is very useful but at the same time I am mindful of it’s limitations and that of RISC OS as well.

Also using the recent example of some games ported in effect the package is only as good as that tested and supplied by the author and that in it’s self can cause issues.

In an ideal world I think a packaged management approach is the way to go and I am thankful for those who have done lots of work on Packman and packaging in general but RISC OS has history so we need to be aware and acknowledge that as well.

I have just tried another package in !Packman – called Shine+ – there is no triangle showing, but still can not tell it where to install ! It again dumps it in a hidden sub-folder within Apps

I give up, its simply too much hassle

but still can not tell it where to install !

To be fair Chris I believe this has been explained before.

Some package location are not configurable and others are.

Once installed you can use Packman to see where they are installed by highlighting the package > menu mouse click > Package “Package name” and then selecting installed files which will tell you everything about what is installed and where.

I do think it would be good if all packages allowed you to select the location and give location details before installing but disregarding something because it doesn’t do it in the old RISC OS way but in a way most other systems work is not entirely fair or logical.

If we want new people to have a familar type environment then we long term users need to see it from their perspective and then once they are in to RISC OS allow them to see other options.

Also has anyone attempted to feedback some suggested improvements to Alan Buckley?

It’s possible to create a Package manually that doesn’t have a components section. If there isn’t one there is no option to change the install location. The folder where it’s installed will default to the section name. In the case of Shine+ it’s audio so it get installed in $.Apps.Audio.