Build lr-mame on 32bit OS but 64bit cpu
-
This is a vero machine with installed Retropie wanting to add lr-mame.
It ends up failing with this:
Compiling src/emu/video/generic.cpp... ../../../../../src/emu/validity.cpp: In function ‘void {anonymous}::validate_integer_semantics()’: ../../../../../src/emu/validity.cpp:179:31: error: static assertion failed: PTR64 flag enabled, but was compiled for 32-bit target 179 | static_assert(sizeof(void *) == 8, "PTR64 flag enabled, but was compiled for 32-bit target\n"); | ~~~~~~~~~~~~~~~^~~~ make[2]: *** [emu.make:2274: ../../../../libretro/obj/libretro/src/emu/validity.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [Makefile:76: emu] Error 2 make: *** [makefile:1359: linux] Error 2Indeed, the architecture is aarch64 (uname -m) but the kernel is 32 bit as shown by getconf LONG_BIT
emu.make does indeed show PTR64=1 but not sure why.
What would be the solution to try and install lr-mame as 32bit? Or is the problem perhaps something else?
-
What would be the solution to try and install lr-mame as 32bit? Or is the problem perhaps something else?
Run a 32bit kernel, so MAME's build program doesn't get confused about the target architecture.
-
Well, I have no choice about that. I may have misunderstood getconf. I believe what I reported means 32 bit userland (getconf), 64 bit kernel (uname). Unfortunately, I am not able to change that for a year or so (awaiting upstream software changes).
Is there a way to build it anyway as 32 bit like retropie/arch was built? mame-2003plus runs but that version doesn't support later machines that I want.
-
Unfortunately, I am not able to change that for a year or so (awaiting upstream software changes).
How come ? Which OS are you using and what device ?
Is there a way to build it anyway as 32 bit like retropie/arch was built? mame-2003plus runs but that version doesn't support later machines that I want.
I don't think we support this kind of configuration - it needs cross-compilation support in the build scripts.
-
I think you should read this topic too :
https://retropie.org.uk/forum/topic/34301/cross-compile-packages-for-rpi1
It might be helpful. -
@Folly Yeah, had read that and hoped PTR64=0 would work but it did not. As I am not on a Pi (see OP) I can't add the config.txt option. I too get lots of PTR64=1 in makefiles despite specifying PTR64=0. Don't know if one could manually adjust the makefiles then build perhaps.
An alternate solution is to simply punt on building lr-mame and instead use standalone mame package with retroarch. I don't know if I want to do that though.
-
@sfatula said in Build lr-mame on 32bit OS but 64bit cpu:
@Folly Yeah, had read that and hoped PTR64=0 would work but it did not. As I am not on a Pi (see OP) I can't add the config.txt option. I too get lots of PTR64=1 in makefiles despite specifying PTR64=0. Don't know if one could manually adjust the makefiles then build perhaps.
Manually adjusting the makefiles would normally be an option but here you have to break the building process as that initially generates these makefiles.
Restarting the building process will probably mean that the makefiles are overwritten again.
So you have to go really deep in order to do what you are suggesting and you also need to use theretropie_packages.shscript in order to be the boss over things.
Ideally it would be the best to specify PTR64=0 as a flag in building process before the makefiles are generated.Not sure where you specified PTR64=0 and you probably also need to specify arm_64bit=0 in order to get it working.
On the pi these are specified as "initial boot vars" not as flags.
However, as you said, you use a vero machine and not a pi.
Therefor you should share exactly your machine info and your OS info in order to see if somehow these vars can be applied to your OS or not.
Personally I think that we will not find the answer to that question.
If that is the case then it's probably best to move to a full 64 bits OS.An alternate solution is to simply punt on building lr-mame and instead use standalone mame package with retroarch. I don't know if I want to do that though.
I see your mixing things up.
FYI, standalone mame doesn't work with retroarch, lr-mame does.
The topic I linked to is about standalone mame and you are talking about lr-mame.
However, basically, they will suffer from the same issue, I believe.Another alternative is to look at my project over here :
https://retropie.org.uk/forum/topic/29682/development-of-module-script-generator-for-lr-mess-lr-mame-and-mame-standaloneI have implemented a way to install binaries for lr-mame, lr-mess and standalone mame that are on my gdrive.
Good chance that some of the binaries will work.
If not then use the 64 bits OS, I suggested, and then install it from source again.
I think that should work. -
@Folly said in Build lr-mame on 32bit OS but 64bit cpu:
Not sure where you specified PTR64=0 and you probably also need to specify arm_64bit=0 in order to get it working.
They're not using RaspiOS nor running on a Raspberry Pi. The
arm_64bitis not available, it's a RPI only configuration. -
Not mixing this up at all. I know mame is not lr-mame. mame however can be run from RetroPie just fine if you configure it as a standalone added emulator. You lose some things.
I'll look at your creation.
-
@Folly So, apt install mame got me standalone compiles for 32 bit of course. Configuring it in retroarch was pretty easy and it works perfectly. It does use a core at 100%, but it does keep up.
But even better, https://github.com/audetto/AppleWin
That is an update to date version of AppleWin with a libretro build on linux! That's more efficient than mame and gives me a libretro module. So, all is well as I compiled that and added to retroarch.
As I said, I am not moving to a 64 bit OS, it's not relevant as to why as that was not my question.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.