Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 489118 - games-emulation/sdlmame-0.149 fails to build
Summary: games-emulation/sdlmame-0.149 fails to build
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Games (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Games
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-23 11:05 UTC by Philipp
Modified: 2015-11-20 06:57 UTC (History)
1 user (show)

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


Attachments
cave info (cave-info.txt,11.71 KB, text/plain)
2013-10-23 11:05 UTC, Philipp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp 2013-10-23 11:05:35 UTC
Generating M68K source files...
obj/sdl64/build/m68kmake obj/sdl64/emu/cpu/m68000 src/emu/cpu/m68000/m68k_in.c

        Musashi v4.90 680x0, CPU32, and ColdFire emulator
        Copyright Karl Stenerud and the MAME team.

In src/emu/cpu/m68000/m68k_in.c, near or on line 2718:
        Unknown M68KMAKE directive [
INT32 ea = M68KMAKE_GET_EA_AY_8;]
make: *** [obj/sdl64/emu/cpu/m68000/m68kops.c] Error 1

!!! ERROR in games-emulation/sdlmame-0.149::gentoo:
!!! In /usr/libexec/paludis/utils/emake at line 30
!!! emake returned error 2

!!! Call stack:
!!!    * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:67)
!!!    * main (/usr/libexec/paludis/utils/emake:30)

diefunc: making ebuild PID 12694 exit with error
die trap: exiting with error.


obj/sdl64/emu/cpu/m68000/m68kops.h, which is generated during the build process, seems to be truncated. I couldn't reproduce the issue with a vanilla build (unpack mame, make NOWERROR=1). I honestly don't know where to start investigating, but it must have something to do with the things that gentoo does to the build.
Comment 1 Philipp 2013-10-23 11:05:59 UTC
Created attachment 361716 [details]
cave info
Comment 2 Julian Ospald 2013-10-23 13:04:27 UTC
* you are building with -O3
* you have unsafe overlays installed
* you don't use portage

if you want to speed things up, fix those 3 things and test again. I will test it in a clean chroot when I have time.
Comment 3 Philipp 2013-10-23 14:59:29 UTC
Ok, I retried with -O2 and it works. The strange thing is, though, that I was able to install sdlmame-0.149 with -O3 at some point.
Comment 4 Julian Ospald 2013-10-23 15:09:02 UTC
(In reply to Philipp from comment #3)
> Ok, I retried with -O2 and it works. The strange thing is, though, that I
> was able to install sdlmame-0.149 with -O3 at some point.

You could test -O3 with different gcc versions. It happens from time to time that -O3 has some regressions on newer gcc's.
Comment 5 Casper Ti. Vector 2014-07-25 04:24:06 UTC
Hello, this seems to be an issue with all versions of games-emulation/sdlmame and games-emulation/sdlmess, and might probably be caused by CRLF line terminators in m68k_in.c.

Adding
    edos2unix src/emu/cpu/m68000/m68k_in.c
to src_prepare() solves the problem, as tested on my machine.

See also:
https://aur.archlinux.org/packages/sdlmess/?comments=all
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=92400
Comment 6 Casper Ti. Vector 2014-07-25 04:52:05 UTC
Well, to clarify, CRLF is not the root cause, but eunixdos really resolves the issue anyway.
Comment 7 Casper Ti. Vector 2014-07-25 08:12:35 UTC
Upon closer investigation, the final culprit seems to be calls to memcpy() with their source and destination regions overlapped.  according to memcpy(3), memcpy() is not for this kind of usage; memmove() should be used instead. This bug was exposed by newer gcc versions, which might resulted in changes in memory layout of binaries that made the misused memcpy() explode.

Below is the patch, which solves the problems with m68kmake.c.  Similar issues might also happen with other source files, but I am too lazy to spot those buggy in 2000+ memcpy() calls.

--- src/emu/cpu/m68000/m68kmake.c       2013-01-11 08:32:48.000000000 +0800
+++ src/emu/cpu/m68000/m68kmake.c       2014-07-25 15:30:42.024367667 +0800
@@ -599,7 +599,7 @@
        if(fgets(buff, nchars, file) == NULL)
                return -1;
        if(buff[0] == '\r')
-               memcpy(buff, buff + 1, nchars - 1);
+               memmove(buff, buff + 1, nchars - 1);
 
        length = strlen(buff);
        while(length && (buff[length-1] == '\r' || buff[length-1] == '\n'))

With this patch applied, the
        edos2unix src/emu/cpu/m68000/m68k_in.c
workaround would no longer be needed.

Finally, I will report this issue (and the solution) to upstream.
Comment 8 ta2002 2014-10-27 10:58:10 UTC
Ran into this on the stable version (games-emulation/sdlmame-0.148_p1-r1) after an upgrade to (newly stable) gcc 4.8.3.

Just for the record, here is the output from portage (with -O2):

Generating M68K source files...
Converting src/emu/uismall.png...
obj/sdl64/build/m68kmake obj/sdl64/emu/cpu/m68000 src/emu/cpu/m68000/m68k_in.c

    Musashi v4.90 680x0, CPU32, and ColdFire emulator
    Copyright Karl Stenerud and the MAME team.

Converting src/emu/layout/dualhovu.lay...
In src/emu/cpu/m68000/m68k_in.c, near or on line 2718:
    Unknown M68KMAKE directive [
INT32 ea = M68KMAKE_GET_EA_AY_8;]
src/emu/cpu/cpu.mak:1292: recipe for target 'obj/sdl64/emu/cpu/m68000/m68kops.c' failed
make: *** [obj/sdl64/emu/cpu/m68000/m68kops.c] Error 1
make: *** Waiting for unfinished jobs....
In file included from src/emu/emu.h:74:0,
                 from src/mame/drivers/thayers.c:13:
src/mame/drivers/thayers.c: In function ‘void construct_address_map_thayers_map(address_map&, device_t&)’:
src/emu/addrmap.h:385:33: warning: typedef ‘read_delegate’ locally defined but not used [-Wunused-local-typedefs]
  typedef read##_bits##_delegate read_delegate; \
                                 ^
src/mame/drivers/thayers.c:592:8: note: in expansion of macro ‘ADDRESS_MAP_START’
 static ADDRESS_MAP_START( thayers_map, AS_PROGRAM, 8, thayers_state )
        ^
src/emu/addrmap.h:386:34: warning: typedef ‘write_delegate’ locally defined but not used [-Wunused-local-typedefs]
  typedef write##_bits##_delegate write_delegate; \
                                  ^
src/mame/drivers/thayers.c:592:8: note: in expansion of macro ‘ADDRESS_MAP_START’
 static ADDRESS_MAP_START( thayers_map, AS_PROGRAM, 8, thayers_state )
        ^
src/emu/addrmap.h:390:17: warning: typedef ‘drivdata_class’ locally defined but not used [-Wunused-local-typedefs]
  typedef _class drivdata_class;
                 ^
src/mame/drivers/thayers.c:592:8: note: in expansion of macro ‘ADDRESS_MAP_START’
 static ADDRESS_MAP_START( thayers_map, AS_PROGRAM, 8, thayers_state )
        ^
make: *** wait: No child processes.  Stop.

Good job in tracking down the problem, and amazed that no one else has yet (some other distributions have been using newer gcc versions for months).

Thanks for the patch.

I do want to ask if there are any security implications due to this error (writing to incorrect memory addresses has always been a security headache).
Comment 9 Casper Ti. Vector 2014-10-27 11:41:00 UTC
If you mean the problem caused by memcpy(), I think the security implications should be minimal: the buggy code resided in the source code of m68kmake, a code generator used only in the compilation and not installed into the user's system, thus chances are that the bug only causes compilation errors when triggered.

That patch has been accepted upstream so newer releases should contain the fix anyway: <https://github.com/mamedev/mame/commit/bbcde3a4> (They moved source hosting to GitHub, see <http://mamedev.org/?p=396>).

BTW, I personally sympathise with the Gentoo games hurd.  This patch has been here for quite a long time, without a dev integrating it into the Portage tree.  They really need more human resources :(
Comment 10 Mr. Bones. (RETIRED) gentoo-dev 2015-11-20 06:57:54 UTC
sdlmame-0.167 is in the tree so file a new bug if you have issues building that version.