libstdc++ in Libs.private?

[Michał Górny]

On Fri, 5 Aug 2016 16:49:49 +0200
Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> 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?

I'm afraid you are facing a problem with no good solution. The root
of the issue is that most of the platforms (if not all) still lack
proper static libraries with dependencies, and people got so used to
the fact that they assume the pkg-config hack-around is the correct
solution.

So in a perfect world, the compiler would take care of it when building
DirectFB, passing appropriate parameters to the linker and the linker
storing them in the static library. But since that doesn't happen...

The next most correct solution would be to actually link the reverse
dependencies using the C++ compiler, and -- more importantly --
the same compiler used to build DirectFB. In other words, you'd either
use the C++ compiler when linking lbreakout2 unconditionally, or after
detecting static linking against DirectFB. Though it's not a clean
thing at all and I don't think you'd really want to deploy it.

More correct solutions laid aside, what you say would be acceptable.
However, if you're going to upstream that change, the configure scripts
would have to somehow detect the correct C++ library used for linking,
and put that one.

After all, please remember that there is no standard C++ ABI and no
common C++ library. libstdc++ is specific to the GNU toolchain. When
using clang, you can optionally use libc++ instead -- in which case
your Libs.private would contain -lc++ instead. There may be also cases
when you'd want to specify the directory for libstdc++ with -L.

So, to summarize, as Tollef suggested, you're best not to use static
linking at all. The second best solution is to use the C++ compiler to
link lbreakout2 but making this conditional is non-trivial, and I can
imagine it's a major hassle for a minor library such as DirectFB. So
your suggested solution would work but you should probably try to cover
varying standard C++ libraries.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/pkg-config/attachments/20160807/9e185f81/attachment.sig>