Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 57524 - Patch needed to use GXMame with XMame 0.84.1
Summary: Patch needed to use GXMame with XMame 0.84.1
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Games (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Games
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-18 15:41 UTC by Shark
Modified: 2005-01-02 02:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch needed to use GXMame with XMame >= 0.84.1 (gxmame-xml.patch,614 bytes, patch)
2004-07-18 15:44 UTC, Shark
Details | Diff
updated xmame 0.86 ebuild for installing the required xml2info binary (xmame-0.86-r1.ebuild,5.77 KB, text/plain)
2004-08-31 09:24 UTC, Andreas Kobara
Details
ebuild for gxmame-0.35cvs-20040901 (gxmame-0.35_pre20040901.ebuild,1.14 KB, text/plain)
2004-09-01 04:34 UTC, Andreas Kobara
Details
gxmame CVS Sources from 20040901 (gxmame-0.35_pre20040901.tar.bz2,284.84 KB, application/octet-stream)
2004-09-01 04:37 UTC, Andreas Kobara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shark 2004-07-18 15:41:05 UTC
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
Comment 1 Shark 2004-07-18 15:44:06 UTC
Created attachment 35714 [details, diff]
patch needed to use GXMame with XMame >= 0.84.1
Comment 2 Ian Weber 2004-07-21 09:49:52 UTC
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.
Comment 3 Shark 2004-08-31 04:01:15 UTC
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
Comment 4 Andreas Kobara 2004-08-31 06:52:45 UTC
You need to supply the libraries for linking:

gcc -O1 -o xml2info xml2info.c -lxmlparse -lxmltok

Andy.
Comment 5 Andreas Kobara 2004-08-31 09:24:49 UTC
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.
Comment 6 Shark 2004-08-31 10:46:54 UTC
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?

Comment 7 Andreas Kobara 2004-08-31 11:05:00 UTC
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.
Comment 8 Shark 2004-09-01 02:52:16 UTC
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. 


Comment 9 Andreas Kobara 2004-09-01 04:34:44 UTC
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.
Comment 10 Andreas Kobara 2004-09-01 04:37:17 UTC
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.
Comment 11 Ian Weber 2004-09-03 07:53:29 UTC
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?
Comment 12 Andreas Kobara 2004-09-03 08:29:36 UTC
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.
Comment 13 Tim Burrell 2004-11-06 17:06:03 UTC
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.
Comment 14 Mr. Bones. (RETIRED) gentoo-dev 2004-11-18 20:04:52 UTC
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.
Comment 15 Kerin Millar 2005-01-02 02:25:31 UTC
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.