When the plugin-engine mapping is not cached in the configuration file,
we were not scanning all the plugins to establish the mapping.
This is a regression from commit: e2d91258b7
This commit reverts the offending commit and implements a proper fix for
the case where there are no dynamic plugins.
Fixes#11300.
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
find -name '*.h' -or -name '*.cpp' | xargs sed -r -i 's@\(([A-Za-z0-9]+)\*\)@(\1 *)@g'
This seems to have caught some params as well which is not undesirable IMO.
It also caught some strings containing this which is undesirable so I
excluded them manually. (engines/sci/engine/kernel_tables.h)
Silences the clang warning:
static data member specialization of '_singleton' must
originally be declared in namespace 'Common'; accepted as a C++0x
extension [-Wc++0x-extensions]
Wrapping "namespace Common {}" around the macro assignment causes clang
to complain about a spurious semicolon, and removing the semicolon at
the end of the macro causes some editors to misbehave.
Changing the requirement of using the macro in one namespace (the
global) to another (Common) seems a small price to pay to
silence a warning.
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
After searching for the right plugin once, the filename will be saved to the config file under the domain 'plugin_files'. The key is the gameid and the value is the plugin file. The backup mechanism is searching plugin by plugin.
svn-id: r55061
The leaky file handles didn't show up when debugging using the shell since that uses the Windows file handles, of which there are many more.
svn-id: r55048
Following lordhoto's suggestion, I implemented a simple allocator that grabs the size of the biggest available plugin in memory. This is an elegant solution to the fragmentation problem, with the caveat that memory is wasted. As such, it's not suited for the DS, so I added a #define to disable it there.
svn-id: r55009
* Remove DLObject virtual methods allocSegment and freeSegment.
As long as all DLObject implementations use memalign + free to
allocate/release segments, there is no point in wrapping those.
This enables further simplifications.
* Add TemplatedELFPlugin template class. Use this instead of explicit
ELFPlugin subclasses.
* Rename DLObject::discard_symtab to discardSymtab
svn-id: r54082
