|
More compile problems 0.179
#359980 - 10/27/16 02:49 PM
|
|
|
Here's the error dump:
Compressing src/emu/layout/snap.lay...
Compiling src/emu/video/generic.cpp...
Compiling src/emu/video/resnet.cpp...
Compiling src/emu/video/rgbgen.cpp...
Compiling src/emu/video/rgbsse.cpp...
Compiling src/emu/video/rgbvmx.cpp...
Compiling src/emu/rendfont.cpp...
Compiling src/emu/rendlay.cpp...
Compiling src/emu/video.cpp...
Archiving libemu.a...
make: *** [makefile:951: windows_x64] Error 2
Home@Starling MINGW64 ~/mameui
$ make -j5 OSD=winui STRIP_SYMBOLS=1
GCC 6.2.0 detected
make[2]: *** No rule to make target '../../../../../src/devices/cpu/m6809/6x09dasm.cpp', needed by '../../../../mingw-gcc/obj/x64/Release/src/devices/cpu/m6809/6x09dasm.o'. Stop.
make[1]: *** [Makefile:79: dasm] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [makefile:951: windows_x64] Error 2
Same error, different component has "no rule." This time it's the 6809 chip.
Any help?
|
|
|
|
Re: More compile problems 0.179
[Re: Zaghadka]
#359981 - 10/27/16 04:13 PM
|
|
|
Just completed a compile of vanilla mame64. Worked fine. Definitely something to do with the UI source.
|
|
|
|
Re: More compile problems 0.179
[Re: Zaghadka]
#359993 - 10/27/16 07:08 PM
|
|
|
Okay, so I've got a handlist of errors.
What I did was I took the offending makefiles from the vanilla compile and substituted. The offending makefiles are "dasm.make" and "skeleton.make".
I did a diff of the files, and dasm.make refers to objects that aren't in the vanilla build:
Code:
***** dasm.make
$(OBJDIR)/src/devices/cpu/m6805/6805dasm.o \
$(OBJDIR)/src/devices/cpu/m6809/6x09dasm.o \
$(OBJDIR)/src/devices/cpu/mb86233/mb86233d.o \
***** DASM_GOOD.MAKE
$(OBJDIR)/src/devices/cpu/m6805/6805dasm.o \
$(OBJDIR)/src/devices/cpu/m6809/6309dasm.o \
$(OBJDIR)/src/devices/cpu/m6809/6809dasm.o \
$(OBJDIR)/src/devices/cpu/m6809/knmidasm.o \
$(OBJDIR)/src/devices/cpu/mb86233/mb86233d.o \
So if you replace "6x09dasm.o" with "6309dasm.o", "6809dasm.o", and "knmidasm.o", you get a valid makefile. This carries over to subsequent lines and references.
Then skeleton.make busts with the following references:
Code:
***** skeleton.make
$(OBJDIR)/src/mame/drivers/harriet.o \
$(OBJDIR)/src/mame/drivers/hazeltin.o \
$(OBJDIR)/src/mame/drivers/hprot1.o \
***** SKELETON_GOOD.MAKE
$(OBJDIR)/src/mame/drivers/harriet.o \
$(OBJDIR)/src/mame/drivers/hprot1.o \
So the solution for skeleton.make was to get rid of the reference to "hazeltin.o"
This leads to an error win osd_winui.make, for which there is no vanilla substitute. The offending reference is:
Code:
make[2]: *** [osd_winui.make:1605: ../../../../mingw-gcc/obj/x64/Release/osd_winui/src/osd/winui/mui_opts.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:19: osd_winui] Error 2
make: *** [makefile:951: windows_x64] Error 2
Removing reference to "mui_opts.o" results in errors on linking, of course.
So something is wrong with dasm.make and skeleton.make, and this is breaking osd_winui.make.
Vanilla mame generates valid makefiles.
I don't know how to attach multiple files with this BBS, but I have all the files and errors documented. I'd be happy to share them.
|
|
|
|
-
[Re: Zaghadka]
#360011 - 10/28/16 12:20 AM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: Zaghadka]
#360013 - 10/28/16 12:53 AM
|
|
|
I can confirm that it builds. Instead of updating my source I just pulled in the full git and it compiled with no trouble whatsoever.
|
cyberdman
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360023 - 10/28/16 03:00 AM
|
|
|
That git code doesn't stay stable for very long. It changes constantly. Why not use the stable release code for your releases?
(If you don't think I'm being impertinent)
Anyway, thanks. Compiling now. Hopefully what I pulled from git is compatible.
|
|
|
|
.
[Re: Zaghadka]
#360025 - 10/28/16 03:12 AM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360027 - 10/28/16 03:22 AM
|
|
|
Yeah. As I suspected, git has changed. I get the following error when trying to compile from a git clone on 10/27 at around 8pm CDT.
Code:
$ make -j5 OSD=winui STRIP_SYMBOLS=1
GCC 6.2.0 detected
Compiling src/osd/winui/mui_opts.cpp...
../../../../../src/osd/winui/mui_opts.cpp: In function 'void save_options(windows_options&, OPTIONS_TYPE, int)':
../../../../../src/osd/winui/mui_opts.cpp:2553:3: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
if (driver != NULL)
^~
../../../../../src/osd/winui/mui_opts.cpp:2555:4: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (opt_type == OPTIONS_SOURCE)
^~
cc1plus.exe: all warnings being treated as errors
make[2]: *** [osd_winui.make:1605: ../../../../mingw-gcc/obj/x64/Release/osd_winui/src/osd/winui/mui_opts.o] Error 1
make[1]: *** [Makefile:19: osd_winui] Error 2
make: *** [makefile:951: windows_x64] Error 2
So does anyone have the particular git clone that this thing compiles with?
|
|
|
|
/
[Re: Zaghadka]
#360028 - 10/28/16 03:25 AM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360029 - 10/28/16 03:26 AM
|
|
|
Okay. 
I don't know how to do that either and I wouldn't know which tag to clone from anyhow.
So basically, we can't compile mameui any more?
I would humbly suggest that you make the source match up with the latest stable release. I know the project is on life support and makes large demands on your free time and skills, but it would make life a lot easier for those of us who roll our own.
Just a thought. Take it for what you will.
|
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360030 - 10/28/16 03:27 AM
|
|
|
Yeah. I compile vanilla mame too, so I keep the toolchain up to date with git. A GCC version mismatch would go a long way to explaining this.
|
|
|
|
/
[Re: Zaghadka]
#360031 - 10/28/16 03:33 AM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360052 - 10/28/16 03:49 PM
|
|
|
I'm sorry man. I usually just grab the .rar package. The mui_opts.cpp on the github website hasn't changed. How do I pull the current code for MameUI?
Okay, nevermind. I found the indentation error and fixed it manually in my local code.
This is what I get now:
Code:
Linking mameui64.exe...
../../../../mingw-gcc/obj/x64/Release/generated/mame/mame/drivlist.o:drivlist.cpp:(.rdata+0x14d18): undefined reference to `driver_kron180'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x7d8): undefined reference to `am2847_base_device::rc_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x7ea): undefined reference to `am2847_base_device::rc_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x829): undefined reference to `am2847_base_device::in_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x83b): undefined reference to `am2847_base_device::cp_w(int)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x84a): undefined reference to `am2847_base_device::cp_w(int)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x85a): undefined reference to `am2847_base_device::in_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x86c): undefined reference to `am2847_base_device::cp_w(int)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x87b): undefined reference to `am2847_base_device::cp_w(int)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x9ba): undefined reference to `am2847_base_device::rc_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.text+0x9c9): undefined reference to `am2847_base_device::rc_w(unsigned char)'
../../../../mingw-gcc/bin/x64/Release/mame_mame/libskeleton.a(hazeltin.o):hazeltin.cpp:(.rdata$.refptr.TMS3409[.refptr.TMS3409]+0x0): undefined reference to `TMS3409'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [mame.make:253: ../../../../../mameui64.exe] Error 1
make[1]: *** [Makefile:952: mame] Error 2
make: *** [makefile:951: windows_x64] Error 2
But on the bright side, it did make it all the way to linking.
Edited by Zaghadka (10/28/16 04:04 PM)
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Zaghadka]
#360064 - 10/29/16 12:36 AM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: redk9258]
#360073 - 10/29/16 12:40 PM
|
|
|
|
|
|
Re: More compile problems 0.179
[Re: redk9258]
#360090 - 10/30/16 04:41 AM
|
|
|
> Pull it like this...
> https://github.com/Robbbert/mameui/archive/master.zip
Thanks. The code at that link compiled, no problems.
Will that link always work? I usually pull the .rar file from https://github.com/Robbbert/mameui/tree/master/docs/release, which is where the link on the MameUI home page goes. I then copy that over vanilla Mame's source. That worked fine up until release 0.178. Then I started to have compile problems, I'm guessing because the builds started to be on some arbitrary snapshot of git daily code instead of stable release code.
If this is the best way to get the source now, John IV may want to link it on the MameUI home page, instead of the release directory. If Robbbert is using git daily builds of Mame instead of release builds, then it makes sense to just pull the entire source from the MameUI repo as you described.
Since you can't get the vanilla code from mamedev and then add the source .rar any more, it might make sense to just stop releasing that .rar file. Of course, that is if the decision to go with a daily snapshot of the source instead of the release code is final. The .rar simply isn't useful if you can't pull the exact snapshot the MameUI source package is expecting.
The good news, however, is that it compiles just fine with GCC 6.2.0, which is in the current toolchain. I don't know why it's treating strict syntax warnings as compile interrupting errors, but I'll happily test it on the current tools for you on each release.
I can report back here when it does and does not compile with the current tools. Let me know.
BTW, I think
Code:
git clone https://github.com/Robbbert/mameui.git
also works for getting the current source for MameUI. Is that right, or will that sometimes pull unstable development code?
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Zaghadka]
#360091 - 10/30/16 05:33 AM
|
|
|
> Will that link always work?
It points to the latest version that Robbbert has.
> If this is the best way to get the source now, John IV may want to link it on the
> MameUI home page, instead of the release directory. If Robbbert is using git daily
> builds of Mame instead of release builds, then it makes sense to just pull the entire
> source from the MameUI repo as you described.
Maybe it is a one time deal. I usually just use the RAR file too.
|
|
|
|
-
[Re: Zaghadka]
#360159 - 11/02/16 08:01 AM
|
|
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360176 - 11/03/16 01:57 AM
|
|
|
Compiled fine once I used OSD=messui.
I'm not having much luck choosing carts for Atari 2600 or Gameboy. What is the proper way to store the software files?
|
|
|
|
-
[Re: redk9258]
#360177 - 11/03/16 02:11 AM
|
|
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360178 - 11/03/16 03:24 AM
|
|
|
I guess software list carts. For example, I have a folder named D:\MAME\software\gameboy\ and have tetris.7z that contains dmg-tra-1.u1. I can load it up through the file manager. But I am lost on the software lists.
|
|
|
|
-
[Re: redk9258]
#360179 - 11/03/16 03:41 AM
|
|
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360180 - 11/03/16 04:29 AM
|
|
|
I think I have it working now. I didn't have my software folder in the ROMS path. What is Software File Base?
So let me get this straight. The hash folder has the files that create software lists. Software has to be either in the ROMS folder or added to the ROMS path. Sound about right?
|
|
|
|
Re: More compile problems 0.179
[Re: redk9258]
#360181 - 11/03/16 05:07 AM
|
|
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: More compile problems 0.179
[Re: Robbbert]
#360189 - 11/03/16 12:10 PM
|
|
|
Thanks Robbbert. I like the changes to the UI so far.
|
|
|
Previous 
Index 
Next 
Threaded 
More compile problems 0.179
Reply
[Re: 
