Library exports symbols from the internal C++ API

[GoogleCodeExporter]

Hi,
the shared library file exports symbols from the internal C++ API. This
should be prevented, for example by a libtool -export-symbols-regex like
"^gme_.*" so only symbols that match this are exported.

The real problem here is, that the way the C++ API is namespaced (i.e. not
at all) there could be symbol conflicts with other libraries.

Original issue reported on code.google.com by slomosn...@gmail.com on 14 Aug 2009 at 8:38

[GoogleCodeExporter]

I don't have the email anymore but I'm pretty sure that blargg had mentioned 
the same 
point to me several months ago. There is already visibility support for recent 
compilers so it's just a matter of only exporting required symbols (and testing 
to 
make sure it's not too restrictive).

Original comment by michael....@gmail.com on 8 Feb 2010 at 3:40

[GoogleCodeExporter]

Correction, by "There is visibility support" I mean that my local system's 
checkout 
has visibility support that I've never committed. :(

I think I was discussing it with blargg so I need to see if I can get in touch 
with 
him again first.

Original comment by michael....@gmail.com on 8 Feb 2010 at 4:04

[GoogleCodeExporter]

Yes, the lack of namespaces is an issue. My main reason for holding off was 
allowing
compatibility with older compilers, as some people still use Visual C++ 6 or
something crazy like that. My future direction for libraries is to have a C 
wrapper
(e.g. gme.h), and consider the C++ interface internal.

We should be adding exporting within several days, so at least when building a 
shared
library, only the gme.h functions will be exported.

Original comment by gbla...@gmail.com on 8 Feb 2010 at 2:18

• Changed state: Started

[GoogleCodeExporter]

The next big version will optionally put everything into namespace blargg. It 
will
also be able to put everything into a namespace of another name. This is to 
solve the
issue of using two of my libraries compiled statically into a program. The 
problem
that otherwise arises is that the common facilities (blargg_vector, Data_Reader,
etc.) would conflict, due to each library defining its own version, and worse, 
each
library possibly defining them differently. Having to keep my common utilities
interface-stable across all my libraries would be a real chore.

Original comment by gbla...@gmail.com on 13 Feb 2010 at 10:44

• Changed state: Fixed