Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Martin Storsjö
> Sent: Sunday, May 8, 2022 10:02 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
> sharing issue on Windows
> 
> On Sat, 7 May 2022, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Martin Storsjö
> >> Sent: Wednesday, April 20, 2022 2:48 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
> sharing
> >> issue on Windows
> >>
> >> Hi,
> >>
> >> I just became aware of the av_fopen_utf8 function - which was
> >> introduced
> >> to fix path name translations on Windows - actually has a notable
> >> design
> >> flaw.
> >
> > Hi Martin,
> >
> > I just became aware that somebody would be compiling ffmpeg like
> > this on Windows and I'm curious regarding the whereabouts..
> >
> >> Background:
> >>
> >> On Windows, a process can contain more than one C runtime (CRT);
> the
> >> system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC
> >> builds, each DLL/EXE can have one statically linked in instead of
> >> linking
> >> against a shared library CRT (and that's actually the default
> >> configuration when building with MSVC).
> >
> > The default configuration for both, EXE and DLL projects is to link
> > to the C runtime dynamically (crt dll).
> 
> No, that's not true. If you invoke e.g. "cl.exe myprog.c" without
> explicitly passing either -MD or -MT, the default is -MT, which is to
> statically link the CRT.

What I meant is when you create a new console project in Visual Studio,
the default is /MD, and the same is true when creating a new dll project.



> >> This means that CRT objects (file descriptors from open(), FILE*
> >> opened
> >> with fopen/fdopen) mustn't be shared across DLLs; such an object
> must
> >> be
> >> opened, accessed and closed within the same DLL.
> >
> > This only happens when you explicitly modify the build configuration
> > to statically link to the CRT.
> 
> No, this is not a custom build configuration. This is the build
> configuration you get if you configure with "configure --enable-shared
> --toolchain=msvc".

Ok, then this is what needs to be fixed. When you configure for "shared",
the exe and dll binaries need to be all compiled with /MD.


> > Why are you compiling it this way?
> > Your earlier patch is from 2013, so you seem to be doing so for
> > quite a while.
> 
> It's not that I'm shipping a production setup built this way. I just
> spent
> a fair amount of work to make ffmpeg work when built with MSVC; both
> built
> as static libraries and as DLLs. And I'd like to keep that working.
> Not
> only on the "seems to work for whatever is covered by fate" level, but
> also on the level of not using constructs that are known to not work.
> 
> As av_fopen_utf8 gets duplicated across the libraries by being in the
> same
> source file as the other functions, it works for all uses across the
> libraries, but doesn't work for uses outside of the libraries
> (fftools,
> external API users). That's why I'm hesitant against increasing the
> use of
> this function in fftools until we have resolve this issue.

Yes I agree to that. I will retract this part of my patchset.


> Also, another fairly common situation where the "different CRTs"
> scenario
> happens if you'd e.g. build the ffmpeg libraries as DLLs with mingw,
> but
> then link against those DLLs with a user application built with MSVC.

AFAIK, it is possible to create DLLs with mingw/MSYS2 in a way that
these can link to a specific version of the MS CRT, but that's just
a side note.

> > Is the file API the only case where you had any trouble?
> 
> As far as I remember, that was the only case of cross-library resource
> sharing issue I ran into at the time.


I'll follow up on this in your other reply.

Thanks,
softworkz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".