Linux rpm openssl.so error

[andykimpe]

Description

undefined symbol: EC_GROUP_new_curve_GF2m, version OPENSSL_3.0.0 - /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/x86_64-linux/openssl.so

Current Behavior:

game not start

Expected Behavior:

game starting and work

Steps To Reproduce:

install pokemon studio rpm

sudo dnf -y install https://github.com/PokemonWorkshop/PokemonStudio/releases/download/v2.1.0/pokemon-studio-2.1.0-1.x86_64.rpm

create new game

start not work

Environment:

Fedora 39 x86_64

Error return on terminal:

PSDK_BINARY_PATH="/usr/lib/pokemon-studio/resources/psdk-binaries/" /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/bin/ruby --disable=gems,rubyopt,did_you_mean Game.rb

PSDK Version : 26.23

An error occured during extensions loading.

Error type : LoadError

Error message : /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/x86_64-linux/openssl.so: undefined symbol: EC_GROUP_new_curve_GF2m, version OPENSSL_3.0.0 - /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/x86_64-linux/openssl.so /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/openssl.rb:13:in require' /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/openssl.rb:13:in<top (required)>' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/tools/GameLoader/3_load_extensions.rb:14:in require' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/tools/GameLoader/3_load_extensions.rb:14:in<top (required)>' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/ScriptLoad.rb:194:in require' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/ScriptLoad.rb:194:inload_tool' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/tools/GameLoader/Z_load_uncompiled.rb:9:in <top (required)>' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/ScriptLoad.rb:194:inrequire' /usr/lib/pokemon-studio/resources/psdk-binaries/pokemonsdk/scripts/ScriptLoad.rb:194:in load_tool' Game.rb:11:in

'

ps for information on Fedora 39 openssl version 3.1.1 and not 3.0.0

sudo dnf -y install openssl-devel Last metadata expiration check: 3:03:50 ago on Sun May 12 12:14:24 2024. Package openssl-devel-1:3.1.1-4.fc39.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete!

[andykimpe]

Would it be possible to have an answer on this issue it's been almost a week and still no answer from you please thank you

[Palbolsky]

Hi. It's possible that Linux binaries are not compatible with Fedora. They are functional on Ubuntu and Debian but it is impossible for us to create a single version that is compatible with all Linux distributions because of the many variants. :/

You can try removing the openssl.so file from /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/x86_64-linux/. If the file is not in this folder, the system libs are used, but there's no guarantee that it will work.

You can also try to get or compile openssl 3.0.0 from Fedora and put it in /usr/lib/pokemon-studio/resources/psdk-binaries/ruby-dist/lib/ruby/3.3.0/x86_64-linux/.

You can also try to compile the binaries yourself, but it's complex. https://gitlab.com/pokemonsdk/litergss2 https://github.com/NuriYuri/Ruby-Fmod https://github.com/NuriYuri/sfemovie

[andykimpe]

except that the installation file that I used and that you provide and an rpm

to remind you of the Linux distributions most used in desktop mode are the following

for debian base distributions

it's Ubuntu

for RedHat base distributions

it's Fedora

Moreover, the installation files in deb format are actually for the base Debian distributions (Ubuntu/Debian/Kali Linux ...)

but the installation files in rpm format are for the basic RedHat distribution (Fedora/RedHat Enterprise/Centos/Alma Linux/Rocky Linux/OpenSuse ...)

except you provide an rpm installation file here

https://github.com/PokemonWorkshop/PokemonStudio/releases/download/v2.1.0/pokemon-studio-2.1.0-1.x86_64.rpm

this must therefore be compatible with Fedora since it is the basic RedHat distribution most used in desktop mode

otherwise what is the point of providing an rpm installation file if it is not compatible on the distribution for which it is intended?

[NuriYuri]

We don't have time to debate. We're an open source project and we don't have the capacity to make it work on all platform by magic. If you don't intent to help us, then stop commenting.

[andykimpe]

ok but you provide binary packages without providing the source files necessary for their compilation

should have in the project for debian base

a debian folder containing at least the following files

debian/control debian/changelog debian/rules

or failing that the source files should be prepared at this time

pokemon-studio_2.1.0.orig.tar.gz pokemon-studio_2.1.0-1.dsc pokemon-studio_2.1.0-1.debian.tar.xz

and for basic RedHat distributions

a pokemon-studio.spec file

which should be found at the root of the project

or by default the rpm source file which should this moment

pokemon-studio-2.1.0-1.src.rpm

apart from that also you do not provide it's files

you tell me that I can recompile openssl in version 3.0.0 I am willing

but nowhere do you provide the compilation parameters that you use for openssl

I also don't see why you compile another version of openssl and ruby instead of using the versions that are already present in the operating system. If there is a reason, it must be explained.

also tell you that you cannot compile packages for all distributions but this is not all true in my opinion you indicate those only for lack of information

In my opinion you think that you are wrong to install machines with the distribution concerned to carry out the necessary compilation

I all agree with you that doing this is way too expensive.

but there are several projects that allow

you have either 2 projects which allow you to compile packages in a chroot specifically adapted to the target distribution on the same machine which are the projects

rpm software mock

https://github.com/rpm-software-management/mock

debian pbuilder

https://salsa.debian.org/pbuilder-team/pbuilder

and there are also projects that allow you to compile source packages online for free. There are 3 of them

Ubuntu Launchpad

https://launchpad.net/

Fedora Copr

https://copr.fedorainfracloud.org/

OpenSuse Build Service

https://build.opensuse.org/

so I see that you are telling me that I can help

I'm not against it but unlike you I'm not a ruby specialist I'm more of a php user basically

and I don't have at least for myself all the necessary information to be able to do the compilation work

now I am available at least until Tuesday evening non-stop

so if you have free time you can perfectly do a vocal and discuss what can be spanked

This would allow us to be able to speak in French since we are both French

If I can understand everything I can do the necessary work for packing the packages, there's no problem

[NuriYuri]

Pokémon Studio and Pokémon SDK are two separate things. Pokémon Studio does not use a single line of ruby (afaik) since it's an Electron project.

Pokémon SDK uses ruby to work and several dependencies that Palbolsky already pointed out (with one that is not necessary at all, sfeMovie).

We don't have a build process for Linux but we have one for MacOS: https://github.com/PokemonWorkshop/PokemonStudio/wiki/Building-PSDK-(on-MacOS)

The requirements are the following:

1. Must use Ruby 3.x.y
2. Must use SFML 2.6.x
3. FMOD is optional (if not used, please compile SFMAudio https://gitlab.com/NuriYuri/sfmlaudio or live without sound)
4. sfeMovie is optional, skip it unless you really need it
5. All the binaries should be portable. (Installing a released game should not involve any compilation process).

Please remember that none of us use Linux in real life (that's not for normies). We'd like to use solutions such as Flatpak but we don't have time to invest on making a reproductible build. If you can figure out with the MacOS instruction that'd be nice.

[andykimpe]

I've already worked on Mac OSX so I should be fine

on the other hand, going for a portable version is a very bad idea and it is this idea which precisely created the incompatibility with the rpm that you currently provide

unlike you I have been a Linux user for 14 years I have worked on quite a few distributions

so I'm speaking to you literally with full knowledge of the facts

generally whether with an Appimage, a Flatpak or a Snap.

you would never have 100% portable version compatibility

This problem is not specific to Linux but to all base Unix distributions

Which also includes Mac OSX distributions

if you create a package on a Mac OSX version 11.3

it will not work on a Mac OSX version 13.4

and conversely it's the same

on Linux same problem whether from one version to another or from one distribution to another there will always be certain distributions or versions which will remain incompatible

this is due to the difference in the versions of glibc present on the different base Unix operating systems (Mac OSX and Linux)

the only portable applications that work correctly are generally small applications that do not depend on glibc

apparently Pokemon Studio does not depend on glibc

but unfortunately after verification this is not the case of Pokemon SDK which requires compilation dependencies which themselves depend on glibc

however there is an exception that of the Canonical snapcraft project (Ubuntu)

they use their own version of glibc which is separate from that of the operating systems

unfortunately the snap project and a rather recent project and even using this one still encountered certain incompatibilities

In my opinion it would be better to create separate packages for each distribution

there will be much less incompatibility and problems this way

so no worries I will do this work

but you would not have the packages straight away

it may take some time, not to mention that it is preferable to thoroughly test the packages of each distribution before officially publishing them

[NuriYuri]

So far no issues on MacOS, maybe thanks to the lack/inexistance of dependency with glibc :)

It's incredible though that in 2024 Windows remains the sole OS being able to work with portable binaries :S (You can have a USB stick with Nodepad++ it will work on any Windows computer that isn't using a EOL version).

My expectation is really that we can distribute a version of Studio with Github pipeline that just works on user computer without any manual action from them. If that's not possible, I'd rather remove the pipeline from our steps and save $$ (so far the Buntu/SteamOS side is OK thanks to the amazing job of Palb')

[andykimpe]

the reason is simply because apple forces users to upgrade to the latest version

this is only because for the moment you do not have this problem

on windows if you were on windows 7

At the time they didn't force you to upgrade.

to windows 8 or windows 10

same with windows 8 you weren't forced to upgrade to windows 10

and it's the same for windows 10 don't force you to upgrade to windows 11

the upgrade and suggest but it is not forced

despite having more support for windows 7

today in 2024 even if it is rare

There are still people who have PCs on Windows 7

on Mac OSX by default upgrades are forced

only certain people who know the system well and who have a second router can block upgrades using a firewall

afterwards I reassure you programs like notepadqq which is probably the Linux equivalent which is closest to notepad++

available in portable version

because they are small programs

vlc and firefox are also available

there is not a lot of program that really depends on glibc in the end

it's only the big programs

or it is adapted to use the dependencies of each system

because on linux unlike windows

you have a lot of things that are preinstalled in the system

for example libreoffice on windows you must install it

where to install microsoft office

and of course linux libreoffice and preinstalled on practically all desktop versions

afterwards I can still try if you really want it but I will have to integrate a different version of glibc and it will take 3 times more time

Moreover, not everyone uses Linux.

so there is no real interest unlike Windows to make portable versions

because if you put your program on a usb key

when you go to another computer there is a 98% chance that it is not a Linux computer but a Windows computer

after all, if you really want it, I'll try anyway

but its risk of creating problems which would be non-existent with independent packages

you risk having a lot of tickets for problems with this portable version

afterwards I can also even by spanning different packages make a single installer

I can make a bash with conditionals adapted to each distribution and use shc to convert it into a single binary file in c

plus you want a portable version

but what you gave was only half portable

because I remind you of the purpose of a portable program

is to be able to run it without administrator rights

except do you give deb and rpm files

which requires administrator rights to be installed

[NuriYuri]

Beware, when I talk about portability I talk about the game that you make with Studio, not Studio. A video game should be as easy to run as putting a disk the disk tray. If it's not working it's not nice.

Deb & rpm are just because electron forge build them, I'd like flatpak instead but have no capacity for it.

Regarding bloating in Linux or Windows, it's out of topic please refrain from trying to justify stuff that doesn't need to be justified.

[andykimpe]

ok I understand better that's why the integrated ruby versions

it is precisely this integration of a portable version of ruby which poses a problem with glibc

but if it's only the final game you want that's portable I think it's feasible

but the user must have ruby which must already be installed in their target operating system

afterward for linux users it's not at all annoying to tell them

to use this game you must install ruby using your package manager

on the contrary, it is even preferable to tell them

rather than giving them a precompiled version which will only cause problems

[NuriYuri]

That'd be ideal but the UX is really bad and it still has one problem:

They will also have to install SFML, install cmake, install all their dependencies, build LiteRGSS2, create an account on fmod.com, download the right version, compile RubyFmod and then drop the compiled dependencies in the right folder so it can be loaded.

That's not the vision we have of a video game ^^' Regardless, we could still go on that way for RedHat linux distro. You can find the condition to detect we're running on RedHat linux distro and we'll apply it instead of removing RPM build of Studio (since the whole app works aside the game).

[andykimpe]

so for SFML yes but it's like ruby it's in the repositories

cmake, LiteRGSS2 and others no I am almost certain to have the solution at this level

on the other hand fmod can probably pose a problem

I still need to think a little more about the issue.

but I'm sure I think it's probably possible

I just need more time to study the matter in depth.

in terms of objectives I set much higher than you

I'm thinking of a minimum compatibility of 12 Linux base operating systems

[andykimpe]

on the other hand what poses a problem to me is that at the level of fmod you do not specify which one to use

it is not indicating whether it is wrong to take

FMOD Studio

FMOD Engine

FMOD for Unity

or FMOD for Unreal

so even I don't know absolutely which one to take

the only sentence you indicate and the following

8. Install FMOD (copy the includes into /opt/homebrew/include and appropriate libs into /opt/homebrew/lib)

[andykimpe]

It’s not FMOD for Unity, that’s for sure

on the other hand even in the others I see clearly

the lib but no include folder already

[NuriYuri]

FMOD Studio is an editor, so by logic it has to be FMOD Engine ;) (Since for Unity is for Unity and for Unreal is for Unreal)

[andykimpe]

ok I found and understood

for lib

fmodstudioapi20222linux/api/core/lib/x86_64/libfmod.so

fmodstudioapi20222linux/api/core/lib/x86_64/libfmod.so.13

fmodstudioapi20222linux/api/core/lib/x86_64/libfmod.so.13.22

fmodstudioapi20222linux/api/core/lib/x86_64/libfmodL.so.13

fmodstudioapi20222linux/api/core/lib/x86_64/libfmodL.so.13.22

for include

fmodstudioapi20222linux/api/core/inc/fmod.cs

fmodstudioapi20222linux/api/core/inc/fmod.h

fmodstudioapi20222linux/api/core/inc/fmod.hpp

fmodstudioapi20222linux/api/core/inc/fmod_codec.h

fmodstudioapi20222linux/api/core/inc/fmod_common.h

fmodstudioapi20222linux/api/core/inc/fmod_dsp.cs

fmodstudioapi20222linux/api/core/inc/fmod_dsp.h

fmodstudioapi20222linux/api/core/inc/fmod_dsp_effects.h

fmodstudioapi20222linux/api/core/inc/fmod_errors.cs

fmodstudioapi20222linux/api/core/inc/fmod_errors.h

fmodstudioapi20222linux/api/core/inc/fmod_output.h

[NuriYuri]

Perfect, what you actually need from lib: All file that are not containing libfmodL (L is for debug or static I don't remember)

What you need for the headers: All the files that that doesn't end with .cs

In theory you could just use the L and I flags for the compiler but unfortunately those are only setup for MacOS (if /opt/homebrew exist, then they're expected in /opt/homebrew/lib and /opt/homebrew/include). Windows uses MSYS2 which provides a good environment for compilation so dropping in lib/include is sufficient.

[andykimpe]

you simply have to put in the linux paths instead of the homebrew one

/usr/include instead of /opt/homebrew/include

and /usr/lib64 instead of /opt/homebrew/lib

[NuriYuri]

I know but I won't. Development libraries should never go into system folders, that's the basis of system security. (And that's why I'd like to have flatpak instead of deb/rpm).

[andykimpe]

I know

after that for the moment I only do tests

once I have all the code adaptations for all distributions

I would make the path adaptations with Unix variables

on the other hand all will be put in /opt at the end

probably /opt/pokemonstudio/root/

so in the end we will have

/opt/pokemonstudio/root/usr/lib64

/opt/pokemonstudio/root/usr/include

[andykimpe]

I will make sure to use the software collection system also called scl

https://www.softwarecollections.org/en/about/

https://access.redhat.com/documentation/en-us/red_hat_software_collections/2/html/packaging_guide/index

binaries compile to scl if all dependencies are included

this makes them compatible with all Linux distributions

this is notably the packing system used by the company bitnami

https://bitnami.com/stacks

xampp also use the same system

https://sourceforge.net/projects/xampp/files/XAMPP%20Linux/8.2.12/xampp-linux-x64-8.2.12-0-installer.run/download

moreover it will allow to have a minimal version for users

and develop packages separate in this way the final version for users will be lighter

because the devel dependencies will be separated

[andykimpe]

I looked for it's the only way to have everything in portable mode

without creating a large binary pack for users

there will also be glibc included but users

we will only have the contents of the glibc package

while the build version will have glibc and glibc-devel

even the gcc compiler will have its own version which will be the

gcc 13.2.1 patch 6.3 (based to CentOS Stream 9 original package gcc-toolset-13-gcc)

http://mirror.stream.centos.org/9-stream/AppStream/source/tree/Packages/gcc-toolset-13-gcc-13.2.1-6.3.el9.src.rpm

but this will only be in devel

[andykimpe]

if I understood correctly what I saw at your level

for the linux builds that you did you used docker on windows

So I imagine that you would prefer that I make you a docker file with the build config?

[NuriYuri]

No, Palb' used a virtual machine under Ubuntu and passed the file to another OS and SteamOS to check that they were working properly.

We also would avoid docker as much as possible since it's a damn complex system and we'd avoid having a PhD to compile binaries. (cmake . is a bit more user friendly than docker tbh)

[andykimpe]

ok in this case I would rather make a config for Fedora Copr

https://copr.fedorainfracloud.org/

with a tutorial and detailed screenshots of each step

it's quite simple to use it's an online compilation system that uses mock

just do 2 - 3 config and can copy paste

because unfortunately mock is no longer available on ubuntu since 16.04

all will be on github and copr

[andykimpe]

see the tutorial in writing sketches

https://github.com/andykimpe/PokemonStudio/blob/develop/linux-build/Readme.md