On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > On 07.09.2023 23:38, Kacper Michajlow wrote: > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > <derek.buitenh...@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++`. > > 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".
