Problem: pc.in assumes usage of lstdc++

[fanquake]

Solution: remove -lstdc++.

A different c++ std lib could be in use. i.e clang++ -stdlib=libc++, so there shouldn't be an assumption that stdc++ is being used.

Originally added in https://github.com/zeromq/libzmq/pull/1398.

[bluca]

Can it be detected and listed at build time? It was added because otherwise static builds don't work

[fanquake]

It was added because otherwise static builds don't work

If users need it for static builds, they can/should at it to their own link flags. It looks like it was only added here for convinience, with the (now incorrect) assumption that only a certain c++ library is in use.

detected and listed at build time?

I think it's odd to force this onto users who aren't building statically, and/or wouldn't even need an explcit std lib link flag. So I'm not sure there is a reason for this to be listed in any case.

[bluca]

Libs.private is used only for static builds, and the whole point is that you don't need to figure out manually what needs to be added and what doesn't. Removing it breaks this and it's a backwards-incompatible breaking change, which is not allowed.

[fanquake]

Note that this also breaks builds in a second way. If you're linking with gcc and -static-libstdc++ you'll get the bogus -lstdc++ on your link line, which undermines the -static-libstdc++ link, and gcc will end up linking libstdc++ shared rather than static.

[bluca]

Breaks compatibility, no fix in more than a year, closing