MAMEWorld Forums - News - Re: Faster MAMEhub released and our new web site

> > Unless this bug has changed since 0.139, recent versions of MinGW/MSYS do not build
> > MAME at all, because of issues with the Makefiles.
>
> The bug hasn't changed, but MAME itself has been largely cleared of GCC 4.6 problems
> in that timeframe. Similarly, Clang 2.9 should work for MAME when it's released as
> we've also been testing there (and they've kindly fixed a bug specifically exposed by
> MAME).
>
> > make depend does not address what I'm talking about: What does address what I'm
> > talking about is replacing drivlist.c with a driver interface and binding the
> drivers
> > at runtime. Then, the code in src/emu/* and mame/drivers/* can be static libraries
> > without creating a circular dependency at link-time. The way the current build
> system
> > handles this is by linking hundreds of .o's into one monolithic executable, which
> > takes forever and breaks building on android.
>
> Now I'm confused, because that's not what the current build system does at all. It
> distills the .os into a few dozen .a static libraries (libemu.a for src/emu, namco.a
> for Namco games, and so on) and then links all the libraries together.
>
> Also, there have been significant changes to how drivlist.c is handled since 0.139.

While it's true that archives are generated from the .o's, they are not treated as static libraries. If they were, you could use ld as the linker instead of g++. As it is now, g++ links every .a and .o together in one step. This negates the benefit of using static libraries, and you might as well be linking every .o and not have .a's at all. If you try to use ld to link MAME, you will realize that there are dependency cycles in the .a's and they can't actually be used as static libraries. This means that build systems like NDK (android) which depend on linking code with ld can't handle MAME's current architecture.

Check out MAMEHub here: http://www.mamehub.info/