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: Monday, May 9, 2022 11:36 AM
> 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 Mon, 9 May 2022, Soft Works wrote:
> 
> >> -----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:
> >>
> >>>> 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.
> 
> I disagree. Both (statically linked or dynamically linked CRT) are
> entirely valid configurations, and ffmpeg works fine (except for this
> particular, so far marginally used, function) in both those build
> configurations.

I don't mean to change this as a measure for dealing with this issue 
and considering it fixed by that. Mixed CRT usage is not really the
typical and definitely not the recommended way to build a bunch of 
applications alongside a bunch of dynamic libraries.
That's why I think that this might be something to consider changing.

Besides that, having mixed runtimes and in general multiple versions
of dynamic libraries loaded in the same process is not only perfectly
valid, it's also one of the key reasons for the unparalleled backwards
compatibility that Windows provides in contrast to Unix based systems.
(what I mean is that a dll or application that was compiled 20 years
ago can still run or in case of a dll be loaded by a current application).


> >> 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.
> 
> Yes, that's true. (As a side note to this side note, I'm the one who
> added
> support for UCRT in mingw-w64 in the first place, so I do know a thing
> or
> two about that.)

Cool :-)


> But in short, yes it's possible to spend effort at making them use the
> same shared CRT, but it's also fairly common to use different CRTs.

Yes, when you're mixing stuff from different sources, or just to name
one example: something like plugins.
But when you build an application alongside a set of libraries - that
is still a bit unusual, isn't it..

I don't actually care as I'm using the SMP project generator, it just
doesn't seem to be a good default IMO.

Kind regards,
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".