From http://x.mame.net Xmame/xmess-0.84.1 is released The -listinfo option is no longer supported, so some front-ends may not work with this release. A quick fix is to have a front-end use -listxml instead and pipe the output to the xml2info utility Reproducible: Always Steps to Reproduce: none The patch for GXMame is available from http://x.mame.net/download/gxmame-xml.patch
Created attachment 35714 [details, diff] patch needed to use GXMame with XMame >= 0.84.1
There's a slight hiccup with this patch: It relies on the xml2info utility which is provided in the MAME sources. Now, as near as I can tell this isn't covered by any of the Makefiles so isn't built by default as part of MAME. A fairly clunky solution is to compile it manually by extracting the MAME sources into a temporary directory, changing to the src/xml2info dir under the main source dir and running the following: gcc -O1 -o xml2info xml2info.c (taken from the xml2info.txt file supplied with the MAME sources) And then copying the resulting executable into a dir in the default search paths (I used /usr/local/bin but /bin or /usr/bin could conceivably be used instead). I'm sure there's a better way of doing it but I lack the skills to implement it.
xml2info didn't compile here (x86+gcc 3.3.4-r1) even by hand. gcc -O1 -o xml2info xml2info.c /tmp/ccOBwnzA.o(.text+0x3b0): In function `process_error': : undefined reference to `XML_GetCurrentLineNumber' /tmp/ccOBwnzA.o(.text+0x13dc): In function `process': : undefined reference to `XML_ParserCreate' /tmp/ccOBwnzA.o(.text+0x1428): In function `process': : undefined reference to `XML_GetErrorCode' /tmp/ccOBwnzA.o(.text+0x1430): In function `process': : undefined reference to `XML_ErrorString' /tmp/ccOBwnzA.o(.text+0x14b0): In function `process': : undefined reference to `XML_SetUserData' /tmp/ccOBwnzA.o(.text+0x14ce): In function `process': : undefined reference to `XML_SetElementHandler' /tmp/ccOBwnzA.o(.text+0x14e4): In function `process': : undefined reference to `XML_SetCharacterDataHandler' /tmp/ccOBwnzA.o(.text+0x1542): In function `process': : undefined reference to `XML_Parse' /tmp/ccOBwnzA.o(.text+0x155c): In function `process': : undefined reference to `XML_ParserFree' collect2: ld returned 1 exit status
You need to supply the libraries for linking: gcc -O1 -o xml2info xml2info.c -lxmlparse -lxmltok Andy.
Created attachment 38592 [details] updated xmame 0.86 ebuild for installing the required xml2info binary added installing of xml2info binary for use with an updated gxmame. Regards, Andy.
Just installed the new ebuild, works flawless here, thanks Andy. BTW, seems that GXMame needs another patch to work with Mame > 0.83. :( Quoting from the XMame 0.86 announcement: WARNING: gxmame is currently not working unless XIL is built in, i.e., on Solaris, because it always expects "-xil" and "-noxil" to be available. This may be the case for other options too. I'll try to whip up a patch for it if someone else doesn't beat me to it. </quote> No patch available for now, seems that the only the cvs version of gxmame works with the new builds. Maybe a diff file cvs vs web-sources is the best solution?
I already tried to make a minimal patch for gxmame too, and I get the gamelist update running again. The bad thing is that it is now crashing with a segfault which I can't track down so far. A current cvs dump might be best solution for now, as there is already a lot of things fixed including the xil stuff.
I've downloaded the cvs-sources but the configure script needs intltool >= 0.31 to run. <quote> checking for intltool >= 0.31... 0.30 found. Your intltool is too old. You need intltool 0.31 or later. </quote> the ebuild in http://bugs.gentoo.org/show_bug.cgi?id=62484 should fix the problem.
Created attachment 38666 [details] ebuild for gxmame-0.35cvs-20040901 Here's an working ebuild for gxmame using the cvs sources from 20040901. Note that you require to have intltool >= 0.31 installed see Bug #62484 for a ebuild as it is not in the portage tree yet. You have to rebuild xmame-0.86 with the patch submitted earlier to have xml2info available in your path.
Created attachment 38667 [details] gxmame CVS Sources from 20040901 As gxmame has no cvs tarballs available for downloading you'll need to checkout gxmame by yourself, or download this attachment. Note: I had to disable NLS, as there where too many errors in handling of pot files. Maybe someone can get deeper into that. Regards, Andy.
This is still broken for me. Even using the ebuilds for xmame 0.86-r1, intltool 0.31.2 and gxmame from here it still bombs with a "No xmame executables found message" even though all 4 xmame executables are in /usr/games/bin which is in the PATH. Anyone know what might be causing this?
Ian, did you configure the directory entries in gxmame ? And if you use /usr/games/bin/xmame make sure that it is linked against one of the xmame.* binaries. You might also need to select a configured executable in the main gui window on top.
gxmame is TOTALLY broken with xmame 0.87, even with all the aforementioned patches applied. It loads the gamelist fine, but apparently all the command line options have changed. ie, there is no longer a -sound option, -geometry apparently doesn't work the same way. Hopefully the gxmame author is working on a new version.
I'm going to mark this as WONTFIX. gxmame developent is fine I'm sure but unless they do releases, I'm not interested in adding their stuff to portage. I've clamped the version of xmame to < 0.84. I don't recommend using gxmame at this time.
I upgraded to xmame-0.89 yesterday and thus became aware of the change. I then grabbed the gxmame-0.35cvs tarball (dated 28th December 2004 according to http://prdownloads.sourceforge.net/gxmame/), prepared an ebuild and discovered that it works perfectly - no hacks or messing around. I used a fake xmame script to peruse the calling syntax and all the options appear to be set as they should be. Furthermore, I cannot reproduce any of the problems that anyone has mentioned in the past. I would ask Mr Bones to reconsider; I realise that there is an implied inconvenience in using tarballs whose contents might "silently" change in the future but, given the infrequent (yet seemingly consistent) rate of gxmame updates, is it really a huge problem? Given that gxmame is actually a nice front-end, that 0.34b continues to work with the version of xmame currenly marked stable in portage, and that the snapshot apparently works with any newer instance of xmame (and would also have an innate dependency on >=games-emulation/xmame-0.84.1 which are masked anyway) then why exactly shouldn't "anyone" use gxmame at this time - snapshot or otherwise? By the way, I believe that the gxmame ebuild is missing an expat dependency and that the xmame ebuild fails to declare mmx in IUSE. I will file these separately.