On Fri, 9 Aug 2013, Martin Storsjö wrote:

On Fri, 9 Aug 2013, Luca Barbato wrote:

On 09/08/13 11:41, Martin Storsjö wrote:
Add one copy of the function into each of the libraries, similarly
to what we do for log2_tab. When using static libs, only one
copy of the file_open.o object file gets included, while when
using shared libraries, each of them get a copy of its own.

This fixes DLL builds with a statically linked C runtime, where
each DLL effectively has got its own instance of the C runtime,
where file descriptors can't be shared across runtimes.

On systems not using msvcrt, the function is not duplicated.
---
 libavcodec/Makefile     |    2 ++
 libavcodec/file_open.c  |    1 +
 libavdevice/Makefile    |    2 ++
 libavdevice/file_open.c |    1 +
 libavformat/Makefile    |    2 ++
 libavformat/file_open.c |    1 +
 libavutil/internal.h    |    4 ++++
 7 files changed, 13 insertions(+)
 create mode 100644 libavcodec/file_open.c
 create mode 100644 libavdevice/file_open.c
 create mode 100644 libavformat/file_open.c


Looks better even if I'm still wondering why adding 3 files referencing
a file whose code doesn't really apply to windows while you should just
keep the utf8 compatibility code in compact and just link it on windows,
avoiding all the duplication and keeping the code more or less where it
belongs.

That would end up more complicated build-system wise.

To clarify this part - this "utf8 compatibility code" needs to be linked into all three of the libs, since this is the one that actually calls open() (or _wopen, _wsopen or which one we actually do call). If the actual CRT open calls weren't inside of this function, it would be possible to do it simpler, but not as things are right now. (And the function tries two different combinations, both interpreting as utf8 and using in native codepage if utf8 didn't work.)

So due to this all this compatibility code needs to be linked into all three extra libs, which means some stub .o file needs to be added to all of them, and this patch is a very non-intrusive way of doing that.

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to