libstdc++ in Libs.private?

[Thomas Petazzoni]

Hello,

Thanks for your feedback. See some comments below.

On Sun, 7 Aug 2016 19:47:03 +0200, Michał Górny wrote:

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

Well, the fact that the dependencies of static libraries are not taken
into account is not a new problem (otherwise pkg-config would have the
Libs.private and Requires.private flags), and I'm not really trying to
fix this general problem here.

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

The problem is that lbreakout2 has no clue a C++ library might enter
the game. Indeed, lbreakout2 is not even using directly a C++ library.
It's using SDL, which is a C library. And it's SDL itself, in some
conditions, that might use a C++ library. I don't see how lbreakout2
can know about this: SDL can grow a new video backend tomorrow, without
the need to change anything in lbreakout2.

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

Sure. Out of curiosity, how would you do that? Is there some existing
autoconf macro that would allow to find what are the appropriate flags
to link against the C++ library?

That being said, DirectFB project is dead (the site has been offline
for many months, and prior to that there hadn't been any release for a
long time) so I'm not even sure upstreaming the change is important.
But since this problem may very well occur for other packages, I'm
interested in understanding what is the "appropriate" way to fix it.

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

Right. Hence my question above on how you would detect the proper flags
to link against the C++ library?

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

See my answer to Tollef: using static libraries is sometimes the only
solution you have, depending on the target architecture.

Thanks again!

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