On Mon, 9 May 2022, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Martin Storsjö
Sent: Sunday, May 8, 2022 10:02 PM
To: FFmpeg development discussions and patches <ffmpeg-
de...@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.
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.)
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.
// Martin
_______________________________________________
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".
