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

[Kacper Michajlow]

On Wed, 6 Sept 2023 at 19:09, Timo Rothenpieler <timo at rothenpieler.org> wrote:
>
> On 06.09.2023 18:54, Kacper Michajlow wrote:
> > On Wed, 6 Sept 2023 at 12:15, Timo Rothenpieler <timo at rothenpieler.org> wrote:
> >>
> >> On 06/09/2023 01:26, Kacper Michajłow wrote:
> >>> Other C++ standard libraries exist. Also, this is not a proper way to
> >>> link the standard library anyway. Instead when a C++ dependency is
> >>> detected, switch to the C++ compiler driver to properly link everything.
> >>>
> >>> Signed-off-by: Kacper Michajłow <kasper93 at gmail.com>
> >>> ---
> >>>    configure | 26 ++++++++++++++++++--------
> >>>    1 file changed, 18 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/configure b/configure
> >>> index bd7f7697c8..f3ff48586a 100755
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -3584,11 +3584,9 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h dev_video_bktr
> >>>    caca_outdev_deps="libcaca"
> >>>    decklink_deps_any="libdl LoadLibrary"
> >>>    decklink_indev_deps="decklink threads"
> >>> -decklink_indev_extralibs="-lstdc++"
> >>>    decklink_indev_suggest="libzvbi"
> >>>    decklink_outdev_deps="decklink threads"
> >>>    decklink_outdev_suggest="libklvanc"
> >>> -decklink_outdev_extralibs="-lstdc++"
> >>>    dshow_indev_deps="IBaseFilter"
> >>>    dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
> >>>    fbdev_indev_deps="linux_fb_h"
> >>> @@ -4984,6 +4982,18 @@ set_ccvars HOSTCC
> >>>    test -n "$cc_type" && enable $cc_type ||
> >>>        warn "Unknown C compiler $cc, unable to select optimal CFLAGS"
> >>>
> >>> +cxx_deps=(
> >>> +    decklink
> >>> +    libglslang
> >>> +    libgme
> >>> +    libopenmpt
> >>> +    librubberband
> >>> +    libsnappy
> >>> +)
> >>
> >> Can't say I'm a fan of maintaining a random list in the middle of
> >> configure, which manually contains all libs we think need libstdc++.
> >>
> >> This could for one change any time. But also, those dependenies might
> >> have other dependencies, which when linking statically might need libstdc++.
> >>
> >> But in general, this seems extremely brittle and a maintenance nightmare.
> >
> > Yes, that's the main problem. Linking static dependencies is an
> > unsolved problem. We can discuss that, but wouldn't you agree that the
> > proposed patch is an improvement over the current status quo? Forcing
> > `-lstdc++` unconditionally, when some of the dependencies are enabled
> > is way worse. The logic of maintaining the list does not change, it is
> > just centralized in one place and properly switches linking language
> > to C++ when needed, instead side-loading stdc++.
>
> It's not really unsolved. The dependencies need to properly advertise
> their dependencies via pkg-config.
> That only becomes an issue if we have some legacy manual detection that
> bypass pkg-config by default, or weird projects that don't supply
> pkg-config files.

No, not really. I've explained why we shouldn't list standard
libraries in pkg-config. No need to repeat myself, feel free to refer
to my previous email.

And in fact I found the exact same discussion on pkg-config ML from a
few years ago.
https://lists.freedesktop.org/archives/pkg-config/2016-August/001053.html

The conclusion mostly matches mine argument, that we should not
include `-lstdc++` in `Libs.private`. Or any other implicitly added
standard lib for that matter.

> > Good solution that would not require any maintenance is to switch to
> > CXX always for linking.
>
> Just test if linking with CC/LD fails, and if it does, test if it works
> with CXX, and if so, use CXX?
> A bit crude, but at least does not cause a maintenance nightmare.

What would be a downside of preferring CXX always if it exists?

- Kacper