Thanks for reporting it and for the merge request. It has been fixed!

Cheers

@roslof This reply is amazingly detailed, thank you for taking the time to write this up. End result: your instructions helped make everything work perfectly and I am now able to run the older versions of lr-mame. Thank you again!

@mitu

I understand I'll just wait until it's released officially. I just got excited because of the version number after updating from source

Thanks
Sim

@dankcushions said in Running out of MEM and SWAP when compiling lr-mame:

@johnodon yes, i pointed you towards the script earlier. however the script provides an informed guess rather than a cast-iron guarantee. normally it's enough.

lr-mame is in the experimental packages for a reason...

Gotcha. Thanks for all your help.

@mitu Compile ffmpeg in due course because attractmode. I have recompiled / updated it adding the parameter --extra-ldflags = "- latomic" .
And now if I have been able to compile retroarch, I have even installed version 1.9.0.

Everything works great now :)

Thanks again for doing this!

@kactius i think that,s happening cuz the pi3 does not support opengl
i have the old halflife port on my pi3 so i cant test it on that since i have it working fine.

and right now im working with my pi4

@sleve_mcdichael said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

What is the significance of the CMakeLists.txt param in ...

The correct way to invoke cmake is

cmake <PARAMS> <path_to_folder_containing_CMakeLists.txt>`

... the && cd build part didn't do anything, so it tried to cmake & make from the wrong dir and, predictably, failed.

Don't use && then, just have the 2 commands separately.

.. this one just built it right there in the main tmp/build/module folder. Do I want to leave it in or out? Does it make a difference?

No, but some programs enforce a separate build folder (out-of-tree build) so you may get an error when building directly in the source folder.

Also, it still made the same file, but it put it in the wrong place. So if I were to use retropie_packages.sh <module> install after this, it would be installing the old one from the "build" dir and not the new one I just built in the wrong place, so this isn't a solution.

If you change the build parameters, then do a cleanup first.

I think I could begin the build function with a [[ -d build ]] && rm -rf build to remove the dir if it exists?

I don't think that when building with cmake this step is necessary, so that's why is not enforced. This is an issue only when repeatedly re-building without cleaning up, so it's more of an artifact of re-trying the build with a 'dirty' state.
You should first compile the program separately - not as a scriptmodule - to get the cmake build options right, then add it to the build function and try it from retropie_packages.sh.

Just to confirm I had email confirmation that the change was merged into master, so post-update I tested again anyway and all works fine.

Thanks for sorting this so quickly.

Cheers

It has nothing to do with the modules, there's something related to the kernel files copied by rpi-update which breaks the compilation - see https://github.com/raspberrypi/firmware/issues/1364.

personally, if i was doing this i would make a fork in github with my changes, and then edit the retropie build script to point at it, then compile it through retropie - update via source.

eg https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/mupen64plus.sh#L32

if i made a change to the master branch of my fork of mupen64plus-core, i would this line to
'dankcushions core'

note that when you edit retropie scripts the script updater will complain when you come to update it.

@mth75 The patches added by the RetroPie install script work only with the branch/version specified in the script. If you'd like to get the latest dev version, you should also remove the .diff being applied.

Thanks for the report, we'll see how it can be fixed.

@dixeflatline
I think you could compile it for armv8a. How much memory does the switch have? You might be able to compile it on the switch.

@littlehui said in emulationstation can not lauche:

lima driver only support opengl es. Is this the problem?

No, actually is the other way around - Emulationstation needs OpenGL ES for your system to work, but it relies on SDL2 to offer that. If your SDL2 library is not compiled with OpenGL ES support, then it won't work. The RetroPie-Setup script takes care of compiling or installing such SDL2 version (for Raspberry PI at least), I'm not sure your system provided SDL2 library has GL ES support and - also important - accelerated GLES support from the Lima driver.

@mitu

Thank you very much for the reply!!

The bad thing is that I do not know how to write code ... and I'm not sure where I should write the commit (eaac037a9e331e8b26a77239d8dd96b76f86515e) and with what syntax ...

Please, if it is not too much trouble, if I could write the line that I should include in the ir-picodrive.sh and in what position, I compile and see if it works !!!

many thanks!!!

Sorry, I thought I did. But that was in another post.

That said, compiling on a threadripper 2990WX with -J80 is almost hilarious. :-)

@mitu That just gives me a segmentation fault. If it's too much trouble then I'll just try asking the person that compiled lr-mess successfully and hope that he can share it. The reason I wanted to try is because the person said he could succesfully run neogeo cd chd games. If latest mame can also do this now, I wonder how much work would it be to backport it for the mame2003-plus guys.