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.
Created attachment 361716 [details] cave info
* 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.
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.
(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.
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
Well, to clarify, CRLF is not the root cause, but eunixdos really resolves the issue anyway.
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.
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).
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 :(
sdlmame-0.167 is in the tree so file a new bug if you have issues building that version.