Re: [FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations
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 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".
Re: [FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations
On Fri, 28 Jul 2023 at 20:55, Nicolas George 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".
Re: [FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations
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. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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 v4 0/4] Fix MSVC build without optimizations
> On 28 Jul 2023, at 12:40, Reimar Döffinger wrote: > > >> On 28 Jul 2023, at 03:37, L. E. Segovia wrote: >> >> Updated for 6.0, any constructive feedback will be appreciated. > > Using #if means the code will not even be compile tested if the > feature is disabled, this makes maintenance especially of rare > features much harder (nevermind code readability). > Also I believe we do not support compiling without optimizations > even on primary platforms like Linux/gcc, so I'd find it very unlikely > we'd want that for MSVC. > At least there would have to be a very good argument why this is so > important to have that we'd accept the drawbacks. Since you asked for constructive feedback: 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. Best regards, Reimar ___ 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 v4 0/4] Fix MSVC build without optimizations
> On 28 Jul 2023, at 03:37, L. E. Segovia wrote: > > Updated for 6.0, any constructive feedback will be appreciated. Using #if means the code will not even be compile tested if the feature is disabled, this makes maintenance especially of rare features much harder (nevermind code readability). Also I believe we do not support compiling without optimizations even on primary platforms like Linux/gcc, so I'd find it very unlikely we'd want that for MSVC. At least there would have to be a very good argument why this is so important to have that we'd accept the drawbacks. Best regards, Reimar ___ 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".
