Copying my report from sf.net: The source uses a mixture of "#ifdef HAVE_CONFIG_H" and "#if HAVE_CONFIG_H" checks. Judging from DEFS=-DHAVE_CONFIG_H in the configure I supposed it should be "#ifdef" in all cases. These incorrect checks cause build errors since it tries to include the config.h on a custom configuration, that doesn't provide one. I can provide a patch, if necessary.
Oliver St?neberg wrote:> Copying my report from sf.net: > > The source uses a mixture of "#ifdef HAVE_CONFIG_H" and "#if HAVE_CONFIG_H" > checks. Judging from > > DEFS=-DHAVE_CONFIG_H > > in the configure I supposed it should be "#ifdef" in all cases. These incorrect > checks cause build errors since it tries to include the config.h on a custom > configuration, that doesn't provide one.Which build method triggers this issue? Autoconf and VSproj based builds should be fine.> I can provide a patch, if necessary.I've already started work on this. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
> Oliver St?neberg wrote: > > > Copying my report from sf.net: > > > > The source uses a mixture of "#ifdef HAVE_CONFIG_H" and "#if HAVE_CONFIG_H" > > checks. Judging from > > > > DEFS=-DHAVE_CONFIG_H > > > > in the configure I supposed it should be "#ifdef" in all cases. These incorrect > > checks cause build errors since it tries to include the config.h on a custom > > configuration, that doesn't provide one. > > Which build method triggers this issue? Autoconf and VSproj based builds > should be fine.None of those. Just pulling out the files necessary and compiling them into a library - that's the way it was done when it was added to MAME/MESS.