[FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking

[Kacper Michajlow]

On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
<derek.buitenhuis at gmail.com> wrote:
>
> On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
> > What would be a downside of preferring CXX always if it exists?
>
> FFmpeg runs in a multitude of environments with a multitude of portability
> requirements. Needlessly linking a C++ runtime is not OK.

This does not answer my question. Let me rephrase. Do we know the case
where using C++ compiler driver rather than C would degrade the
quality of the resulting build?

Using C++ driver would indeed append the (correct) runtime library to
the linker command, but if nothing references any symbols from it it
would not be linked. It is also why the current way of forcing
`lstdc++` kinda works, because it is silently ignored when not needed.

Implementing logic to use C++ only when necessary is possible, but I'm
not a big fan of such automation. And in practice not sure how well it
would work, because it would require trying to link twice every
dependency in configure.

Also the fact that "FFmpeg runs in a multitude of environment" is
precisely why I really don't like the current unconditional including
`-lstdc++`.

> Further, we do not generally automatically change build output based on
> what is available on the system.

I must kindly disagree. configure has 35 components marked as
`[autodetect]` and they are certainly changing the build output based
on what's available on the system. Whether it is intended or
historical behaviour is another question. But I'm also not proposing
to auto detect anything, quite the opposite with this silly manual
list of libraries.

- Kacper