On Wed, 6 Sept 2023 at 19:09, Timo Rothenpieler <t...@rothenpieler.org> wrote: > > On 06.09.2023 18:54, Kacper Michajlow wrote: > > On Wed, 6 Sept 2023 at 12:15, Timo Rothenpieler <t...@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 <kaspe...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
