Hi all, Yes, the linking step bails out with optimizations disabled under MSVC. The rest of the compilers perform DCE even at -O0, but under Windows, the /FORCE:UNRESOLVED linker flag is needed to work around this.
As for the stub generation -- given the amount of places that these patches touch, and that someone would need to figure out a complete configuration to test them all, I believe it's very much infeasible. Conversely, hooking into the macro uses makes testing as simple as one run with /O2 and another with /O0 -- which we use in development as well. best, amyspark On 28/07/2023 10:21, Matt Oliver wrote: > On Fri, 28 Jul 2023 at 20:55, Nicolas George <geo...@nsup.org> wrote: > >> Reimar Döffinger (12023-07-28): >>> I assume the issue is missing symbols during linking? >>> If you really want this, why not create a file that provides dummy >>> symbols for all that are missing, concentrating the #if mess in >>> a single place and avoiding affecting any of the regular code, and thus >>> having no impact at all when compiling with optimizations. >>> Yes, it's likely to be a good bit of maintenance effort for those who >>> want to use it, but at least anyone not caring about this feature can >>> ignore it, so at least I would not have a reason to be against it. >> >> This is an interesting idea. It would even be possible to include a tool >> that generate these stubs directly from the linker's errors, reducing >> the maintenance. >> >> Maybe even make the stubs static inline functions rather than actual >> linking symbols. >> > > The issue with dead code elimination and msvc has been raised many times > over the years and the general response has been to not support it. The > last discussion was back in 2016 ( > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) which > apparently was by me. > There was an attempt previously by someone to try and semi-manually add all > the missing symbols using dummy functions but it obviously didnt go > anywhere as if I remember correctly it was difficult to track them all down > for all possible configuration options and maintaining it was just too hard > and it never got completed. I dont have the link but if you crawl through > old mailing list posts it is in there somewhere. > > About a decade ago I went the auto generation route and created a tool that > generated Visual Studio projects by scanning ffmpegs make/configure files > and as part of that the tool creates dummy files with all the missing > symbols for the requested configuration options ( > https://github.com/ShiftMediaProject/FFVS-Project-Generator). Its not the > most readable code but it does work. Whats potentially more interesting is > over all the years that project has been used the number of dummy dce stubs > has decreased from what used to be there when some of those early attempts > I mentioned were made. However just checking it now shows that there are > still a good 1000 dummy functions created for avcodec alone, although > admittedly theres only about a dozen for all the other libs. So a > pre-processing tool can work nicely, the trick is to be able to get it to > work with different compilers as the command line options and output format > is slightly different and that only gives you the function name you still > need to then scan the code to work out the correct types for the functions > parameters and return types in order to make a dummy stub. > _______________________________________________ > 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". -- amyspark 🌸 https://www.amyspark.me _______________________________________________ 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".
