libstdc++ in Libs.private?

[Michał Górny]

On Tue, 9 Aug 2016 11:07:55 +0200
Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> On Sun, 7 Aug 2016 19:47:03 +0200, Michał Górny wrote:
> > 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.

Yes, you are correct here. So if you go this way, you either:

a. account for the cases you are aware of -- you could e.g. check
library list returned by pkg-config for known-C++ libraries,

b. account for the generic possibility -- i.e. use C++ compiler
unconditionally.

Not saying either of the options is perfect. There is also
the alternative of saying it's a corner case, and user is supposed to
handle it if he wishes to -- e.g. by setting CC to a C++ compiler (not
sure if lbreakout2 would be happy about that).

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

Not to my knowledge. And I have no idea how you would do that.

CMake for example attempts to find some linking details by calling
compiler in verbose mode (e.g. ${CC} -v) and attempting to parse
the output for linker calls. It's awfully dumb and fragile, so not
something I'd recommend anyone to do.

But even if you did that, you'd still have to figure out which of
the -l flags actually correspond to the standard C++ library. You could
go crazy to the point of linking a test C and C++ program,
and comparing the list of libraries used -- but that probably still
wouldn't be perfect or cover all the cases.

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

I was actually wondering why you're even interested in DirectFB. But I
agree this is a generic problem that can occur anytime C++ libraries
expose C ABI. But as said above, I don't know a really good solution to
it and I honestly doubt anyone does.

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

Well, I guess you can't do much in this case. Once again, this is
pretty much a very specific corner case (rare architecture, rare
kind of dependency) with no good solution. I personally think
the effort would be better spent introducing a better static library
format.

-- 
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/20160810/6967d9fb/attachment.sig>