MAMEWorld Forums - Programming - Re: libmame patch discussion please

> > MESS was built as a single large .dll with two smaller exe (MESS and MESSUI) which
> > used extensively the .dll. the issue was that this made debugging with GDB
> basically
> > useless (symbols got basically lost in the .dll passage)
>
> The other problem is that GCC on Windows has no way to control global symbol
> visibility, so any symbol that isn't local is exported. And the Windows dynamic
> loader gets *extremely* slow in the presence of a DLL with more than about 1500
> exported symbols, even on very fast systems. M1 on Windows has this problem - it's
> why there's a long dramatic pause when you start either the CLI frontend or Bridge. I
> build Audio Overload in Visual Studio for precisely that reason, and AO boots up
> instantaneously in spite of having a very similar amount of code to M1.

Maybe I'm doing something wrong, but I am using a linker version script when building libmame on Windows to export only the LibMame symbols from the .dll. Here is the script:

Code:


{
	global: LibMame_*;
	local: *;
};

The result of using this version script (gcc option --Wl,--version-script=libmame.version) is that libmame.dll only exports about two dozen LibMame symbols and nothing else.

This is sufficient for libmame since only its external API should be seen by anybody; all of the other MAME symbols that are defined for drivers, etc, are not needed outside.

Of course, if you want to do debugging, then you'll have to turn this off, but if you're doing debugging, just built the thing statically.

EDIT:

I'd like to also mention, as an aside, that the PIC requirement for shared object libraries on Linux makes MAME run approximately 10% slower than without PIC. When I benchmarked using libmame as a shared object library, I got approximately 10% worse frames per second (games running unthrottled) than when compiling libmame as a static library.

For most games, this hardly matters, but for those for which that 10% takes the game from always playable to sometimes hiccuping, you could just compile libmame as a static library (no PIC code) and link your program like that. You end up with a ginormous program but if you're in a dedicated environment like a cabinet, it's acceptable.

In fact aside from disk space there is hardly a reason to use libmame as a shared object library (unless you are a pure C program which cannot link against static libmame); it's not like you're going to get the benefit of sharing copies of the library in memory since you're not going to be running two MAME engines at the same time ...

Edited by Bryan Ischo (11/10/11 08:18 PM)