[CMake] Building a static C library with internals in C++

Eric BOIX eboix at ens-lyon.fr
Fri May 5 08:22:50 EDT 2006


	Dear cmake users,

Consider a library (let's call it MyLib) whose internal code is written
in C++ and whose API is written in C (in order not to constrain MyLib users
to use C++ vs C). Hence MyLib is the aggregation of the compilation of
C source files (e.g. for the code implementing the API itself) and of C++
source files.

Now consider a user of MyLib trying to link his C written calling code
user.c against MyLib. Add the fact that this is a nice and behaved user
that uses cmake for his building process. :)

Now, they are two cases depending on the choice of library he made when
he build MyLib: either a dynamic (or shared) library or a static library
(which corresponds respectively to ON and OFF for the BUILD_SHARED_LIBS
cmake internal variable).

1/ When MyLib library was build in shared mode, then cmake properly build
  a MyLib.so (on linux for illustrating things) which correctly depends on
  libstdc++ (which can be seen e.g. with "ldd MyLib.so"). This is because the
  command generated by cmake to build MyLib.so is based on g++ (sorry for
  the GNU bias) which calls the linker and adds on the fly the required
  libs e.g. libstdc++. [Don't quote me on this one, though].
  Nevetheless when the user links his C compiled user.o against MyLib.so things
  run smoothly.

2/ BUT when MyLib library was build in static mode, the produced MyLib.a has no
  reference to libstdc++. This is because the command used to build MyLib.a
  is now simply "ar" (which has no knowledge of the internals of the
  object files it is aggregating).
  Hence when the user links his C compiled user.o against MyLib.a the
  linker fails to resolve the symbols required by the C++ part of MyLib
  (which are in libstdc++)...
  Allthough this can be fixed manually by linking with g++ this is not
  really satisfying for the user...who has no reason to specify
  libstdc++ as target library to it's EXECUTABLE target (for the good
  reason that he might not even be aware of the fact that MyLib uses C++
  for it's internals).

Here is my question:
how to deal cleanly (i.e. in a nice portable cmake way) with such a situation ?


     Thanks,
     Respectfuly yours,
     Eric Boix.


More information about the CMake mailing list