libstdc++ in Libs.private?

[Thomas Petazzoni]

Hello,

I'm facing a specific static linking issue, which I can solve by adding
-lstdc++ in Libs.private, but I'm not sure how correct this is. See
below for the complete context.

The build error is visible at:

  http://autobuild.buildroot.net/results/b05/b0573be43645c70aeb08fed0b4d732382b0c62ad/build-end.log

Essentially what happens is:

 * We are trying to link statically an application, called lbreakout2.
   This application is written in C, so it's built with gcc.

 * This application is linked against the SDL library, which is also
   written in C.

 * SDL itself is linked against the DirectFB library, which it uses as
   the video backend. The critical aspect is that DirectFB is written
   in C++.

So, when lbreakout2 gets linked, it is linked using 'gcc', and
therefore it is not linked with libstdc++, which causes the huge amount
of undefined references to C++ related symbols visible in the build
output.

I believe that it's the responsibility of the library implemented in
C++ to expose the fact that it needs to be linked with libstdc++, so my
initial feeling for this problem would be to adjust the pkg-config file
of DirectFB to contain -lstdc++ in its Libs.private (I've tested and it
indeed fixes the build issue, as expected).

The directfb.pc.in file (which is used to generate directfb.pc)
currently contains:

Libs: -L${libdir} -ldirectfb @THREADLIB@ @OSX_LIBS@
Libs.private: -L${libdir} @LIBM@ @DYNLIB@ @ZLIB_LIBS@

Changing that to:

Libs: -L${libdir} -ldirectfb @THREADLIB@ @OSX_LIBS@
Libs.private: -L${libdir} @LIBM@ @DYNLIB@ @ZLIB_LIBS@ -lstdc++

solves the problem.

Is this the most appropriate solution? How is this situation of a C
application statically linked against a C++ library typically handled?

Thanks for your insights,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com