|
Help compiling broken HBMAME on Linux
#365223 - 04/16/17 03:01 AM
|
|
|
Hello, having difficulties compiling HBMAME 0.184 under Linux/GCC 6.2.0. Older HBMAME versions compiled just fine. The code is now broken.
I'm sure others are getting the same issue, but can anyone suggest what might be done to fix it? Here's what I get:
Code:
Building driver list... 2589 driver(s) found Compiling generated/hbmame/hbmame/drivlist.cpp... Linking hbmame64... ../../../../linux_gcc/bin/x64/Release/hbmame_hbmame/libkaneko.a(kaneko16.o): In function `device_finder::findit(bool)': kaneko16.cpp:(.text._ZN13device_finderI21kaneko_pandora_deviceLb0EE6finditEb[_ZN13device_finderI21kaneko_pandora_deviceLb0EE6finditEb]+0x23): undefined reference to `typeinfo for kaneko_pandora_device' collect2: error: ld returned 1 exit status hbmame.make:250: recipe for target '../../../../../hbmame64' failed make[2]: *** [../../../../../hbmame64] Error 1 Makefile:196: recipe for target 'hbmame' failed make[1]: *** [hbmame] Error 2 makefile:1242: recipe for target 'linux_x64' failed make: *** [linux_x64] Error 2
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Shoegazr]
#365304 - 04/20/17 10:24 AM
|
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Robbbert]
#365310 - 04/21/17 12:54 AM
|
|
|
> I pushed out a change a few days ago in an attempt to fix this. > > Please try it out.
That worked and it compiles now - thanks, Robbbert. However, now when I run the binary as follows:
$ hbmame monaco
I get:
Value 1 not supported for option sound - falling back to auto Segmentation fault
...and it crashes.
If I try:
$ hbmame monaco -sound none
I only get:
Segmentation fault
...and it still crashes.
Also: unrelated to the above, the following should compile JUST the Monaco G.P. driver according to MAME, but doesn't currently:
Code:
$ make SOURCES=src/hbmame/drivers/monaco.cpp ... ../../../../../src/hbmame/drivers/monaco.cpp:175:21: fatal error: monaco.lh: No such file or directory #include "monaco.lh" ^ compilation terminated. mame_mame.make:277: recipe for target '../../../../linux_gcc/obj/x64/Release/src/hbmame/drivers/monaco.o' failed make[2]: *** [../../../../linux_gcc/obj/x64/Release/src/hbmame/drivers/monaco.o] Error 1 Makefile:91: recipe for target 'mame_mame' failed make[1]: *** [mame_mame] Error 2
I'm happy to troubleshoot both of these issues, just let me know.
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Shoegazr]
#365311 - 04/21/17 03:23 AM
|
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Robbbert]
#365326 - 04/21/17 06:29 PM
|
|
|
> The data in your ini files is out of date. Value 1 indicates you have sound 1 in a > file somewhere.
Yes, that's what the sound issue was. I've started with a fresh ini and no more complaints about sound. Thanks.
I've narrowed down the crashing issue: it only crashes if I load roms from a remote mount point. For example:
WORKS: $ hbmame monaco -rompath /home/shoegazer/roms monaco
DOESN'T WORK: $ hbmame monaco -rompath /mnt/shoegazer/roms monaco
Curiously, this works too: $ hbmame monaco -samplepath /mnt/shoegazer/samples monaco
(roms are loaded locally). The samples are in a zip file just like the roms.
I'm just not sure why this new build of HBMAME crashes when loading roms remotely, and only roms. Older HBMAME builds and MAME 0.184 have no problem with it.
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Shoegazr]
#365338 - 04/22/17 01:15 AM
|
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Robbbert]
#365355 - 04/22/17 04:58 PM
|
|
|
> > I've narrowed down the crashing issue: it only crashes if I load roms from a remote > > mount point. For example: > > > > WORKS: > > $ hbmame monaco -rompath /home/shoegazer/roms monaco > > > > DOESN'T WORK: > > $ hbmame monaco -rompath /mnt/shoegazer/roms monaco > > > > Curiously, this works too: > > $ hbmame monaco -samplepath /mnt/shoegazer/samples monaco > > I don't know anything about Unix, what you have there means nothing to me.
The /home directory is a local mount point - e.g. files/folders located on the same drive as the OS and HBMAME. The /mnt directory can have remote mount points - e.g. shared network drives where files/folders are remote to the OS and HBMAME
> > I'm just not sure why this new build of HBMAME crashes when loading roms remotely, > > and only roms. Older HBMAME builds and MAME 0.184 have no problem with it. > > Maybe try it out with the new MAME. After all, HBMAME is just MAME with different > roms.
Good idea. I tried it out with a MAME I compiled this morning, and it works just fine from a remote mount point. For example:
WORKS: $ mame64 pacman -rompath /mnt/shoegazer/roms pacman
Yesterday I tried doing a "git bisect" for you in an attempt to find the exact commit that caused the problem; however the older builds of HBMAME don't appear to compile with "make TARGET=hbmame". Can you tell me what I can use for a build from say December 2016?
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Shoegazr]
#365356 - 04/22/17 05:05 PM
|
|
|
|
|
Re: Help compiling broken HBMAME on Linux
[Re: Robbbert]
#365357 - 04/22/17 06:28 PM
|
|
|
> You cannot apply the source to the MAME release source, you have to pull from github > to the tag. Back then tags had random names, you'll need to look at the list of them. > I don't know the specific git commands. Also, tags have not always been in use and it > won't be easy to try making an old build.
I assume by "tag" you mean the hash value of the commit. I've done that for the HBMAME github repo, using tag values for "good" and "bad" builds as the git bisect command requires it. Regardless, it sounds like it would be too difficult to attempt a git bisect.
So for reference/convenience, here is the scenario of things that work and don't work. I'm happy as always to help you troubleshoot and fix this bug.
DOESN'T WORK: $ hbmame -rompath /mnt/shoegazer/roms monaco
WORKS: $ hbmame -rompath /home/shoegazer/roms monaco
WORKS: $ hbmame -samplepath /mnt/shoegazer/samples monaco WORKS: $ mame64 -rompath /mnt/shoegazer/roms pacman
UPDATE: I compiled a new HBMAME from a post-0.186 git snapshot and it's working again. I assume it was due to a bug in MAME somewhere between 0.184 and 0.186 affecting ROM paths.
|
|
|