Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
Le keskiviikkona 6. syyskuuta 2023, 2.26.29 EEST Kacper Michajłow a écrit : > 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 > --- > 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 > +) Hard-coding "-lstdc++" is admittedly a brittle kludge. On some systems, the C++ runtime has a different name for one. But hard-coding the set of library that would require the C++ linker is just as much of a hack. I would argue it's even more of a kludge. If a certain runtime (C++ or other) is necessary for a library then it should be in Libs.static in the pkg-config manifest. From there, FFmpeg should pick it up if and *only* if the libarry is linked statically. Indeed, there are no reasons to even force C++ linking to use a C++ *shared* library exposing a pure C interface. Thus, I don't think that forcing the C++ linker is correct. (Also I more or less agree with Timo here.) -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 20:46, Kieran Kunhya wrote: > > On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote: > > > On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > > > > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow > > wrote: > > > > > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > > > 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? > > > > > > > > > > The machine that ffmpeg is being compiled on is not necessarily the one > > > that ffmpeg is going to be run on. > > > > Not sure how this is relevant to the discussion? > > > > > > > > What would be a downside of preferring CXX always if it exists? > > Because it forces a dependency on libstdc++ even if another machine does > not have it. On all "affected" platforms, configure already adds -Wl,--as-needed, so the resulting library has exactly the same dependencies. Unless something references symbols from stdlib, but then it would just not link with clang anyway. ~ clang++ m.o -Wl,--as-needed && ldd a.out linux-vdso.so.1 (0x7ffeeb912000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f64050a7000) /lib64/ld-linux-x86-64.so.2 (0x7f64052ad000) ~ clang m.o -Wl,--as-needed && ldd a.out linux-vdso.so.1 (0x7ffe1fb36000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5e7a3c2000) /lib64/ld-linux-x86-64.so.2 (0x7f5e7a5c8000) - 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On 08.09.2023 20:55, Kacper Michajlow wrote: On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel wrote: On 07.09.2023 23:38, Kacper Michajlow wrote: On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis 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++`. Couldn't you just check if stdc++ is in the ldflags/extralibs, and if so, remove it, and use g++ to link? Well, I'm lost now. Are you suggesting building on top of existing hacks is a better solution than the proposed patch? The proposed patch looks like a near unmaintainable hack to me as it is. Anything that's less brittle is highly preferred. There is no good solution here, but I'm very much against any solution that has high potential for random breakages and hard to predict side-effects. I refuse supporting any kind of random `-lstdc++` adding in configure and then removing it in the end. - 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel wrote: > > On 07.09.2023 23:38, Kacper Michajlow wrote: > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > 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++`. > > Couldn't you just check if stdc++ is in the ldflags/extralibs, and if > so, remove it, and use g++ to link? Well, I'm lost now. Are you suggesting building on top of existing hacks is a better solution than the proposed patch? I refuse supporting any kind of random `-lstdc++` adding in configure and then removing it in the end. - 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote: > On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow > wrote: > > > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > > 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? > > > > > > > The machine that ffmpeg is being compiled on is not necessarily the one > > that ffmpeg is going to be run on. > > Not sure how this is relevant to the discussion? > > > > > What would be a downside of preferring CXX always if it exists? Because it forces a dependency on libstdc++ even if another machine does not have it. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow wrote: > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > 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? > > > > The machine that ffmpeg is being compiled on is not necessarily the one > that ffmpeg is going to be run on. Not sure how this is relevant to the discussion? - 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On 07.09.2023 23:38, Kacper Michajlow wrote: On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis 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++`. Couldn't you just check if stdc++ is in the ldflags/extralibs, and if so, remove it, and use g++ to link? ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow wrote: > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > 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? > The machine that ffmpeg is being compiled on is not necessarily the one that ffmpeg is going to be run on. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis 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 ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
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. Further, we do not generally automatically change build output based on what is available on the system. - Derek ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Wed, 6 Sept 2023 at 19:09, Timo Rothenpieler wrote: > > On 06.09.2023 18:54, Kacper Michajlow wrote: > > On Wed, 6 Sept 2023 at 12:15, Timo Rothenpieler > > 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 > >>> --- > >>>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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On 06.09.2023 18:54, Kacper Michajlow wrote: On Wed, 6 Sept 2023 at 12:15, Timo Rothenpieler 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 --- 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. 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. ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
On Wed, 6 Sept 2023 at 12:15, Timo Rothenpieler 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
> > ---
> > 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++.
Good solution that would not require any maintenance is to switch to
CXX always for linking.
> > +for l in ${cxx_deps[@]}; do
> > +enabled $l && ld_default=$cxx
> > +done
> > +
> > : ${as_default:=$cc}
> > : ${objcc_default:=$cc}
> > : ${dep_cc_default:=$cc}
> > @@ -6706,12 +6716,12 @@ enabled libfribidi&& require_pkg_config
> > libfribidi fribidi fribidi.h fri
> > enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h
> > hb_buffer_create
> > enabled libglslang && { check_lib spirv_compiler
> > glslang/Include/glslang_c_interface.h glslang_initialize_process \
> > -lglslang -lMachineIndependent -lOSDependent
> > -lHLSL -lOGLCompiler -lGenericCodeGen \
> > --lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
> > -lSPIRV-Tools -lpthread -lstdc++ -lm ||
> > +-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
> > -lSPIRV-Tools -lpthread -lm ||
> > require spirv_compiler
> > glslang/Include/glslang_c_interface.h glslang_initialize_process \
> > -lglslang -lOSDependent -lHLSL -lOGLCompiler \
> > --lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
> > -lSPIRV-Tools -lpthread -lstdc++ -lm; }
> > +-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
> > -lSPIRV-Tools -lpthread -lm; }
> > enabled libgme&& { check_pkg_config libgme libgme gme/gme.h
> > gme_new_emu ||
> > - require libgme gme/gme.h gme_new_emu -lgme
> > -lstdc++; }
> > + require libgme gme/gme.h gme_new_emu -lgme;
> > }
> > enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
> > check_lib libgsm "${gsm_hdr}"
> > gsm_create -lgsm && break;
> > done || die "ERROR: libgsm not found"; }
> > @@ -6770,7 +6780,7 @@ enabled libopencv && { check_headers
> > opencv2/core/core_c.h &&
> > enabled libopenh264 && require_pkg_config libopenh264 openh264
> > wels/codec_api.h WelsGetCodecVersion
> > enabled libopenjpeg && { check_pkg_config libopenjpeg "libopenjp2
> > >= 2.1.0" openjpeg.h opj_version ||
> > { require_pkg_config libopenjpeg
> > "libopenjp2 >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
> > -DOPJ_STATIC; } }
> > -enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >=
> > 0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create -lstdc++ && append
> > libopenmpt_extralibs "-lstdc++"
>
Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
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
---
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.
+for l in ${cxx_deps[@]}; do
+enabled $l && ld_default=$cxx
+done
+
: ${as_default:=$cc}
: ${objcc_default:=$cc}
: ${dep_cc_default:=$cc}
@@ -6706,12 +6716,12 @@ enabled libfribidi&& require_pkg_config
libfribidi fribidi fribidi.h fri
enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h
hb_buffer_create
enabled libglslang && { check_lib spirv_compiler
glslang/Include/glslang_c_interface.h glslang_initialize_process \
-lglslang -lMachineIndependent -lOSDependent
-lHLSL -lOGLCompiler -lGenericCodeGen \
--lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lstdc++ -lm ||
+-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lm ||
require spirv_compiler
glslang/Include/glslang_c_interface.h glslang_initialize_process \
-lglslang -lOSDependent -lHLSL -lOGLCompiler \
--lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lstdc++ -lm; }
+-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lm; }
enabled libgme&& { check_pkg_config libgme libgme gme/gme.h
gme_new_emu ||
- require libgme gme/gme.h gme_new_emu -lgme
-lstdc++; }
+ require libgme gme/gme.h gme_new_emu -lgme; }
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create -lgsm
&& break;
done || die "ERROR: libgsm not found"; }
@@ -6770,7 +6780,7 @@ enabled libopencv && { check_headers
opencv2/core/core_c.h &&
enabled libopenh264 && require_pkg_config libopenh264 openh264
wels/codec_api.h WelsGetCodecVersion
enabled libopenjpeg && { check_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version ||
{ require_pkg_config libopenjpeg "libopenjp2 >= 2.1.0"
openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } }
-enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >= 0.2.6557"
libopenmpt/libopenmpt.h openmpt_module_create -lstdc++ && append libopenmpt_extralibs "-lstdc++"
+enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >=
0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create
enabled libopenvino && { { check_pkg_config libopenvino openvino
openvino/c/openvino.h ov_core_create && enable openvino2; } ||
{ check_pkg_config libopenvino openvino
c_api/ie_c_api.h ie_c_api_version ||
require libopenvino c_api/ie_c_api.h
ie_c_api_version -linference_engine_c_api; } }
@@ -6789,12 +6799,12 @@ enabled librav1e && require_pkg_config librav1e "rav1e
>= 0.5.0" rav1e.
enabled librist && require_pkg_config librist "librist >= 0.2.7"
librist/librist.h rist_receiver_create
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp
librtmp/rtmp.h RTMP_Socket
-enabled librubberband &&
[FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking
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
---
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
+)
+for l in ${cxx_deps[@]}; do
+enabled $l && ld_default=$cxx
+done
+
: ${as_default:=$cc}
: ${objcc_default:=$cc}
: ${dep_cc_default:=$cc}
@@ -6706,12 +6716,12 @@ enabled libfribidi&& require_pkg_config
libfribidi fribidi fribidi.h fri
enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h
hb_buffer_create
enabled libglslang && { check_lib spirv_compiler
glslang/Include/glslang_c_interface.h glslang_initialize_process \
-lglslang -lMachineIndependent -lOSDependent
-lHLSL -lOGLCompiler -lGenericCodeGen \
--lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lstdc++ -lm ||
+-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lm ||
require spirv_compiler
glslang/Include/glslang_c_interface.h glslang_initialize_process \
-lglslang -lOSDependent -lHLSL -lOGLCompiler \
--lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lstdc++ -lm; }
+-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt
-lSPIRV-Tools -lpthread -lm; }
enabled libgme&& { check_pkg_config libgme libgme gme/gme.h
gme_new_emu ||
- require libgme gme/gme.h gme_new_emu -lgme
-lstdc++; }
+ require libgme gme/gme.h gme_new_emu -lgme; }
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create
-lgsm && break;
done || die "ERROR: libgsm not found"; }
@@ -6770,7 +6780,7 @@ enabled libopencv && { check_headers
opencv2/core/core_c.h &&
enabled libopenh264 && require_pkg_config libopenh264 openh264
wels/codec_api.h WelsGetCodecVersion
enabled libopenjpeg && { check_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version ||
{ require_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } }
-enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >=
0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create -lstdc++ && append
libopenmpt_extralibs "-lstdc++"
+enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >=
0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create
enabled libopenvino && { { check_pkg_config libopenvino openvino
openvino/c/openvino.h ov_core_create && enable openvino2; } ||
{ check_pkg_config libopenvino openvino
c_api/ie_c_api.h ie_c_api_version ||
require libopenvino c_api/ie_c_api.h
ie_c_api_version -linference_engine_c_api; } }
@@ -6789,12 +6799,12 @@ enabled librav1e && require_pkg_config
librav1e "rav1e >= 0.5.0" rav1e.
enabled librist && require_pkg_config librist "librist >= 0.2.7"
librist/librist.h rist_receiver_create
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp librtmp/rtmp.h
RTMP_Socket
-enabled librubberband && require_pkg_config librubberband "rubberband >=
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
librubberband_extralibs "-lstdc++"
+enabled librubberband && require_pkg_config librubberband "rubberband >=
1.8.1" rubberband/rubberband-c.h rubberband_new
enabled libshaderc&& require_pkg_config spirv_compiler "shaderc >=
2019.1" shaderc/shaderc.h shaderc_compiler_initialize
enabled libshine &&
