I just wanted to add that these types of link errors have a high cost as we usually find them late in production and the workflow to fix them is cumbersome. We have patched our quarantine file a couple of times by now and we're looking forward to have a better way to handle this.

If there are any updates on this, or anyone else experiencing the same issues, do let us know.

I thought more about this issue, and now I believe that using `FT_S(foo)' (or probably even shortened to `_(foo)' instead of `foo') is indeed a too offensive change since it would be necessary to apply it to all source code files, everywhere, making the code really, really ugly.

Looking up the various references you've given, I now believe that libpng's approach is the one what we should follow if a symbol prefix is requested.

1. Compile a static version of the library.

2. Use `nm' to automatically extract the symbols and construct a header file from it.  This should be also part of the tarball so that platforms without `nm' succeed in compilation, omitting steps 1 and 2 (in other words, those two steps are only performed during a direct build from the git repository).

3. Compile the library again, using the just created header file to rename all global symbols (both functions and static data structures).

Hi Werner,

Getting back to this issue I think the symbol dumping solution would add a dependency on the compiler tools (like nm) and be a portability issue.

Searching for other well-known libraries confronted with the same issue I've found that libpng is using the following approach:

```
Starting with libpng-1.6.0, you can configure libpng (when using the
"configure" script) to prefix all exported symbols by means of the
configuration option "--with-libpng-prefix=FOO_", where FOO_ can be any
string beginning with a letter and containing only uppercase
and lowercase letters, digits, and the underscore (i.e., a C language
identifier).  This creates a set of macros in pnglibconf.h, so this is
transparent to applications; their function calls get transformed by
the macros to use the modified names.
```

The build scripts generate the prefixed symbols controlled with the PNG_EXPORT.

Also in this case, there will be a dependency on the build system used by freetype which is not guaranteed to be the same as in the end-user case (most probably).

zlib also uses a similar (but weaker) approach with a compiler define which just adds a predefined prefix to their exported symbols.

/*

• If you really need a unique prefix for all types and library functions,
• compile with -DZ_PREFIX. The "standard" zlib should be compiled without it.
• Even better than compiling with -DZ_PREFIX would be to use configure to set
• this permanently in zconf.h using "./configure --zprefix".

 */

It works in their case as is has fewer symbols than libpng.

For FreeType we could take libpng approach and modify FT_EXPORT but it would imply a massive refactoring. Unfortunately I think there are other symbols that are exported not explicitly through FT_EXPORT (as ft_smooth_renderer_class_pic_free for instance).

I'm unsure what approach is the best one for FT but let's discuss.

Thank you,
Mihai

Graham, what do you think of the suggested FT_SYMBOL solution?  This should be generic enough to be used it with C++ also...

Your suggestion looks nice, and I could live with it, thanks – provided you take the time and send a patch...

On the other hand: Are there other, well-known libraries that try something similar?

Well, it's not about `switching over' but simply wrapping FreeType into a separate namespace while compiling the C library with a C++ compiler.  There won't be any incompatibilities with (older) C compilers.

A user can quite easily customize `ft2build.h', adding the macros you propose.  However, this is rather a C than a C++ solution.  Additionally, no special support within FreeType is necessary for your suggestion.

I have already successfully enclosed FreeType in a C++ namespace as part of using it for my product, CartoType; to avoid conflicts with other versions of FT when linking it statically.

Here are my notes:

My product, CartoType, is sometimes supplied as a static C++ library, and lately I've had some problems reported by users who also link to other libraries containing conflicting versions of open-source components, including FreeType, Zlib, Libpng, Libjpeg, Expat, etc.

One possible fix would be to take these components out of CartoType, and allow users to link to their own versions, but that would compromise consistency and maintainability. Therefore my solution has been to move everything into the CartoType namespace; which means compiling the code as C++ and enclosing all declarations and definitions in "namespace CartoType { ... }". Doing this has helped a number of my clients.

It may interest FreeType aficionados if I give a brief overview of how to do this. My description is based on a somewhat older version of FreeType, but I am sure it remains applicable.This is not the same as creating a C++ wrapper for FreeType. It does not change the FreeType API, but puts everything into the C++ namespace, so that, for example the full signature of FT_Init_FreeType becomes

CartoType::FT_Error CartoType::FT_Init_FreeType(CartoType::FT_Library* alibrary)

Obviously any namespace would work here.

Here's the process I followed:

1. Rename all directly compiled .c files to .cpp. These are files that are not #included, but are part of the main project. So ftbase.c, ftinit.c, truetype.c, raster.c, etc., become ftbase.cpp, ftinit.cpp, truetype.cpp, raster.cpp, etc. The renaming is not absolutely necessary (you could just tell your compiler to compile everything as C++) but it makes things a lot easier if you are working on five different platforms, with many different project files and compilers; all the compilers I use infer C or C++ from the file extension.

2. Change FT_LOCAL, etc, as follows:

#define FT_LOCAL( x )      x
#define FT_LOCAL_DEF( x )  x
#define FT_BASE( x )  x
#define FT_BASE_DEF( x )  x
#define FT_EXPORT( x )  x
#define FT_EXPORT_DEF( x )  x
#define FT_EXPORT_VAR( x )  extern  x
#define FT_CALLBACK_DEF( x )  x
#define FT_CALLBACK_TABLE extern
#define FT_CALLBACK_TABLE_DEF extern

That is, various 'extern "C"' and 'static' qualifiers are removed.

3. Make FT_BEGIN_HEADER and FT_END_HEADER into the start and end of the namespace:

#define FT_BEGIN_HEADER namespace CartoType {
#define FT_END_HEADER } // namespace CartoType

For this to work, I had to remove FT_BEGIN_HEADER and FT_END_HEADER from pshalgo.h, because it #includes other headers; while 'extern "C"' can be nested, a nested namespace is a different namespace.

4. Put all indirectly compiled .c files into the namespace. These are the source files which were not renamed to .cpp files, and are #included by them. They are compiled as C++ because they become part of the same compilation unit when #included. For example, the file ttdriver.c acquires 'namespace CartoType {' after all its #include statements, and '} // namespace CartoType' at the end of the file. I had to do that to about 40 files.

5. Fix up some annoyances in ftinit.cpp. The ordinary system for module specification doesn't work, for reasons I am too bored to investigate involving static object initialisation, 'extern' declarations and strict type checking, so I have to declare the modules like this:

extern const FT_Module_Class psaux_module_class;
extern const FT_Module_Class psnames_module_class;
extern const FT_Module_Class pshinter_module_class;
extern const FT_Renderer_Class ft_raster1_renderer_class;
extern const FT_Module_Class sfnt_module_class;
extern const FT_Renderer_Class ft_smooth_renderer_class;
extern const FT_Driver_ClassRec tt_driver_class;
extern const FT_Driver_ClassRec t1_driver_class;

#define FT_USE_MODULE( x )  (const FT_Module_Class*)&x,

  const FT_Module_Class*  const ft_default_modules[] =
  {
#include FT_CONFIG_MODULES_H
    0
  };

6. There were some other small problems - pretty obvious stuff - but I won't go into them because they have almost certainly been made obsolete by changes to FreeType.

I have used the same technique for libpng, zlib, expat and libjpeg. (I had some trouble with sqlite, so (for the moment) I have left it in C and avoided namespace conflicts by a massive global renaming, adding a prefix to all symbols.) Yes, I am aware that C and C++ are not entirely compatible, but this has not caused any difficulties, apart from trivial matters like casting the return value of malloc from void* to the desired pointer type in a couple of places, and (in zlib) changing old-style C function declarations to the current C and C++ syntax.